이상한 상황: 텍스트 파일이 존재하지만 존재하지 않습니다.

이상한 상황: 텍스트 파일이 존재하지만 존재하지 않습니다.

내 시스템 Fedora 12의 단일 일반 텍스트 파일 문제에 대해 완전히 혼란스러워합니다. 나는 생물정보학 분야에서 알려진 소프트웨어인 Maker를 사용하여 수많은 일반 텍스트 파일을 생성했는데 그 중 하나는 "접근할 수 없는" 것처럼 보였습니다.

Clon1918K_PCC1.gff특히, ... 명령을 사용하면 내 파일이 나열되는데, 등을 통해 해당 파일에 접근 ls, ls -a, ls -li하려고 하면 cat, vim, cp, ls항상 같은 오류가 발생합니다 Clon1918K_PCC1.gff: No such file or directory.

그런데 모든 파일 cp *.gff이나 cp *이 파일을 복사하면 같이 복사가 됩니다.

저도 문제없이 노틸러스로 열어봤는데, 두 경우 중 하나에서는 내용을 같은 이름의 다른 파일에 복사하면 문제가 사라졌습니다. 흥미롭게도 이 경우 이상한 파일은 다시 작성되지 않았으며 정확히 동일한 이름을 가진 2개의 파일이 나타났습니다. 하나는 액세스 가능하고 다른 하나는 액세스할 수 없습니다. 숨겨진 캐릭터를 찾아보는데 모든 게 괜찮은 것 같아요.

이 이상한 사건에 대해 생각이 있는 사람이 있나요? 감사해요!

답변1

동일한 디렉터리에 동일한 이름을 가진 두 개의 파일이 있을 수 없습니다. 정의에 따르면 파일 이름은 고유 키입니다.

당신이 가지고 있는 것은 거의 확실히 특별한 성격입니다. 당신이 그걸 확인했다는 건 알지만, 정확히 어떻게요? ls *gff | hexdump -C특수 문자가 있는 위치를 찾아 보세요와 같이 말할 수 있습니다 . 높은 비트가 설정된 바이트(예: 80및 사이의 16진수 값 FF)는 문제를 나타냅니다. 아래 20(10진수 32)도 특수 문자입니다. 또 다른 팁은 .오른쪽 텍스트 열에 점이 있다는 것입니다 hexdump -C.

UTF-8에는 US ASCII 문자처럼 보이는 문자가 많이 있습니다. US ASCII에서도 1과 l은 비슷하게 보이는 경우가 많습니다. 그런 다음 키릴 문자 C(U+0421), 그리스 초승달 시그마(U+03F9, C와 똑같음), 키릴 문자/그리스어 소문자 "o" 등이 있습니다. 이것들은 볼 수만 있습니다. 눈에 보이지 않는 유니코드 문자가 많이 있을 수 있습니다.


설명하다:높은 비트 표현에 문제가 있는 이유는 무엇입니까? 파일 이름 "Clon1918K_PCC1.gff"는 100% 7비트 US ASCII인 것으로 보입니다. 이를 전달하면 hexdump -C다음과 같은 결과가 생성됩니다.

00000000  43 6c 6f 6e 31 39 31 38  4b 5f 50 43 43 31 2e 67  |Clon1918K_PCC1.g|
00000010  66 66                                             |ff|

이 바이트 값은 0x80모두 7비트 US ASCII 코드 포인트이기 때문에 아래에 나와 있습니다(비트 8이 지워짐). 유니코드 코드 포인트 U+0000 ~ U+007F는 전통적인 7비트 US ASCII 문자를 나타냅니다. 코드 포인트 U+0080 이상은 다른 문자를 나타내며 UTF-8에서 2~6바이트로 인코딩됩니다(Linux에서는 man utf8이를 수행하는 방법에 대한 많은 정보를 얻으십시오). 정의에 따르면 UTF-8은 US-ASCII 코드 포인트를 자체적으로 인코딩합니다. 즉, 16진수 ASCII 문자 41, 유니코드 U+0041은 단일 바이트로 인코딩됩니다 41. 코드 포인트 ≥ 128은 2~6바이트로 인코딩됩니다.각각은 8번째 비트가 설정되어 있습니다.. 이렇게 하면 ASCII가 아닌 문자의 존재를 쉽게 감지할 수 있습니다.스트림을 디코딩할 필요가 없습니다.. 예를 들어 파일 이름의 세 번째 문자 "o"(ASCII, U+006F)를 6f"ο"와 같이 유니코드 문자 "U+03FB GREEK SMALL LETTER OMICRON"으로 바꾼다고 가정합니다. hexdump -C그러면 다음이 생성됩니다.

00000000  43 6c ce bf 6e 31 39 31  38 4b 5f 50 43 43 31 2e  |Cl..n1918K_PCC1.|
00000010  67 66 66                                          |gff|

세 번째 문자는 이제 UTF-8 시퀀스로 인코딩되며 ce bf각 바이트에는 8번째 비트가 설정됩니다. 이 경우에는 곤경에 처했다는 신호입니다. 또한 hexdump7비트 ASCII 디코딩만 단일 UTF-8 문자 디코딩에 실패하고 인쇄할 수 없는 문자 두 개( ..)를 표시합니다.

답변2

노틸러스를 사용하여 파일 이름을 바꾸되 원하는 이름을 입력하십시오(복사하여 붙여넣지 마십시오). 이렇게 하면 특수 문자가 확실히 제거됩니다. 파일 이름 앞뒤에 공백이 있을 수도 있으며 사용자에게는 보이지 않지만 운영 체제와 프로그램에는 표시됩니다. 저는 보통 정말 이상한 파일 이름을 만들 때 mc를 사용합니다.

답변3

루트킷의 존재를 생각해 본 적이 있습니까? 옛날 옛적에 저는 루트킷이 설치된 Solaris 컴퓨터에 액세스할 수 있었습니다. ls *01또는 를 사용할 때는 "*01"이라는 이름의 파일이 표시되지 않지만 ls -altr를 사용할 때는 표시되지 않습니다 echo *01. 루트킷(및 기타 여러 실행 파일) 설치가 ls일부 파일 및 프로세스가 정상적으로 표시되지 않도록 변경되었습니다. 귀하의 설명은 제가 만난 루트킷과 매우 유사합니다.

답변4

누군가가 이것을 우연히 발견하고 다른 답변을 읽는 경우...할 수 있다일부 답변에서 말하는 것처럼 와일드카드를 사용하여 많은 어려움을 겪거나 도박을 하거나 그냥 사용하십시오. ls -b"바이너리"인 것을 기억합니다.

셸의 탭 완성은 자동으로 이 문자를 인용해야 하지만 셸이 아닌 항목(예: Nautilus)을 사용하거나 셸 이스케이프 인용 스타일을 사용하여 ls다른 명령에 대해 미리 인용된 편리한 문자열을 생성할 수 있습니다. 나는 다른 곳의 또 다른 긴 답변에서 이 이상한 파일 예제를 사용했지만 여기서도 관련이 있습니다.

sauer@lightning:/tmp/test> ls
a??file
sauer@lightning:/tmp/test> ls --quoting-style=shell-escape
'a'$'\t\033''file'
sauer@lightning:/tmp/test> mv -v 'a'$'\t\033''file' regular_filename
renamed 'a'$'\t\033''file' -> 'regular_filename'

관련 정보