☰

mime-info에서 텍스트/일반 모드 "*,v"를 공유하는 이유는 무엇입니까?

tag-icon • tag-icon mime-types freedesktop rcs
mime-info에서 텍스트/일반 모드 "*,v"를 공유하는 이유는 무엇입니까?

freedesktop.org 미디어 유형 데이터베이스 shared-mime-info에는파일 이름 패턴*,vMIME 유형과 연관되어 있는데 그 text/plain이유를 이해할 수 없습니다. 왜냐하면 ,v과 는 *,v기본적으로 검색어로 쓸모가 없기 때문입니다!

이 패턴에 대한 2008 커밋을 추가했습니다.설명하지 않지만 테스트 사례에서는 지적합니다.RedHat Bugzilla의 버그. 거기에서 누군가 "RCS 파일"로 끝나는 파일 이름을 가지고 있었는데 ,v오디오 파일로 인식되었다는 오류가 발생했습니다. 추가 컨텍스트가 없으면 "RCS 파일"이 레이더 단면 데이터나 Autodesk ReCap 스캔 파일이 아닌 개정 제어 시스템을 참조한다고 추측할 수 있습니다.

왜 이 사용자의 이상한 경험이 모든 사람을 변화시켰나요 shared-mime-info? 이것이 광범위한 문제입니까? 어쩌면 RCS가 그 결말을 가진 파일을 생성하기 때문일까요? shared-mime-info이러한 무작위 파일이 오디오로 처리되는 이유를 알아내는 대신 오류†에 대한 적절한 응답 에 이것을 추가하는 이유는 무엇입니까 ?

† 저는 "수정" 대신 "대응"이라고 말합니다.했다사용자 문제를 해결하십시오. 이 버그는 명시적으로 원인이 밝혀지지 않은 이후 버전의 소프트웨어에 더 이상 나타나지 않으므로 닫혔습니다 shared-mime-info.

답변1

,vRCS는 다음 접미사를 사용하여 파일을 생성합니다 .

$ mkdir RCS
$ echo hello > hello.txt
$ ci hello.txt 
RCS/hello.txt,v  <--  hello.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test file
>> 
initial revision: 1.1
done
$ ls RCS
hello.txt,v

그리고 원본 파일과 완전히 똑같아 보이지는 않으므로 실제로는 다른 파일로 식별하는 것이 현명할 수도 있습니다.

$ cat RCS/hello.txt,v 
head    1.1;
access;
symbols;
locks; strict;
comment @# @;


1.1
date    2021.08.28.14.44.57;    author ilkkachu; state Exp;
branches;
next    ;


desc
@test file
@


1.1
log
@Initial revision
@
text
@hello
@

또한 행 기반 방식이기는 하지만 적어도 일부 이진 데이터를 처리할 수 있는 것으로 보입니다.

왜 오디오 파일로 인식되는지 모르겠습니다.

답변2

질문에 스스로 답할 수 있을 만큼 충분한 정보가 있습니다. "*,v"는 RCS에 체크인된 오디오 파일이 오디오 파일로 해석되는 것을 방지하기 위해 존재합니다(파일 형식이 다르기 때문에 시도하면).놀다그들을).

RCS 파일에는 다음이 포함될 수 있습니다.바이너리데이터를 또 다른 "문자열"로 취급하기 때문입니다. 이것매뉴얼 페이지이것은 별로 자세하게 언급되지 않았습니다:

문자열은 다음에 포함되어 있습니다.@. 문자열에 다음이 포함된 경우@, 두 배로 늘려야 합니다. 그렇지 않으면 문자열에 임의의 이진 데이터가 포함될 수 있습니다.

프로그램별로 구별할 수 있는 여러 가지 오디오/비디오 형식이 있습니다(예:file) 파일의 내용을 확인합니다. 그러나 MIME은 이름, 특히 파일을 식별하도록 설계되었습니다."접미사"), 일부 시스템에서는 파일 이름만 사용하여 MIME 유형을 자동으로 추론하려고 시도합니다. 이는 본질적으로 오류가 발생하기 쉬우며 '*,v'구현을 수용하기 위한 해결 방법입니다.

관련 정보