Ich bin völlig verblüfft über ein Problem mit einer einzelnen Nur-Text-Datei in meinem System Fedora 12. Ich habe eine bekannte Software aus der Bioinformatik, Maker, verwendet, um viele Nur-Text-Dateien zu erstellen, und eine davon scheint „unzugänglich“ zu sein.
Insbesondere wird mein Dateiname Clon1918K_PCC1.gffaufgelistet, wenn ich ls, ls -a, ls -li...-Befehle verwende, aber wenn ich versuche, über usw. darauf zuzugreifen, cat, vim, cp, lserscheint immer der gleiche Fehler Clon1918K_PCC1.gff: No such file or directory.
Wenn ich jedoch alle Dateien mit cp *.gffoder cp *diese Datei kopiere, wird sie auch kopiert.
Außerdem habe ich versucht, es ohne Probleme mit Nautilus zu öffnen, und in einem von zwei Fällen verschwand das Problem, als ich den Inhalt in eine andere Datei mit demselben Namen kopierte. Interessanterweise wird in diesem Fall die seltsame Datei nicht neu geschrieben und es erscheinen zwei Dateien mit genau demselben Namen, von denen eine zugänglich und die andere nicht zugänglich ist. Ich habe nach versteckten Zeichen gesucht, aber alles scheint in Ordnung zu sein.
Hat jemand eine Idee zu diesem seltsamen Fall?? Danke!
Antwort1
Sie können nicht zwei Dateien mit demselben Namen im selben Verzeichnis haben. Dateinamen sind per Definition eindeutige Schlüssel.
Was Sie haben, ist mit ziemlicher Sicherheit ein Sonderzeichen. Ich weiß, dass Sie danach gesucht haben, aber wie genau? Sie könnten etwas sagen wie: ls *gff | hexdump -Cum herauszufinden, wo die Sonderzeichen sind. Jedes Byte mit dem höchsten gesetzten Bit (das heißt, Hexadezimalwerte zwischen 80und FF) ist ein Hinweis darauf, dass etwas schiefgelaufen ist. Alles darunter 20(dezimal 32) ist ebenfalls ein Sonderzeichen. Ein weiterer Hinweis ist das Vorhandensein von Punkten .in der rechten Textspalte von hexdump -C.
Es gibt zahlreiche Zeichen, die in UTF-8 wie US-ASCII-Zeichen aussehen. Sogar in US-ASCII können 1 und l oft ähnlich aussehen. Dann gibt es das C aus dem Kyrillischen (U+0421), das griechische Mondzeichen Sigma (U+03F9, auch genau wie ein C), das kyrillische/griechische Kleinbuchstabe „o“ usw. Und das sind nur die sichtbaren. Es gibt eine ganze Reihe unsichtbarer Unicode-Zeichen, die darin enthalten sein könnten.
Erläuterung:warum zeigt das höchste Bit an, dass etwas schiefgelaufen ist? Der Dateiname „Clon1918K_PCC1.gff“ scheint 100 % 7-Bit US ASCII zu sein. Wenn man es durchführt, hexdump -Cwird folgendes ausgegeben:
00000000 43 6c 6f 6e 31 39 31 38 4b 5f 50 43 43 31 2e 67 |Clon1918K_PCC1.g|
00000010 66 66 |ff|
Alle diese Bytewerte liegen darunter 0x80(8. Bit frei), da es sich um 7-Bit-US-ASCII-Codepunkte handelt. Die Unicode-Codepunkte U+0000 bis U+007F stellen die traditionellen 7-Bit-US-ASCII-Zeichen dar. Die Codepunkte U+0080 und höher stellen andere Zeichen dar und sind als zwei bis sechs Bytes in UTF-8 kodiert (unter Linux finden Sie man utf8viele Informationen dazu, wie dies gemacht wird). Per Definition kodiert UTF-8 US-ASCII-Codepunkte als sich selbst (d. h. das Hex-ASCII-Zeichen 41, Unicode U+0041, wird als einzelnes Byte kodiert 41). Codepunkte ≥ 128 sind als zwei bis sechs Bytes kodiert,bei denen jeweils das achte Bit gesetzt ist. Das Vorhandensein eines Nicht-ASCII-Zeichens kann leicht erkannt werden durchohne den Stream dekodieren zu müssen. Angenommen, ich ersetze das dritte Zeichen im Dateinamen, „o“ (ASCII 6f, U+006F), durch das Unicode-Zeichen „U+03FB GRIECHISCHER KLEINBUCHSTABE OMIKRON“, das wie folgt aussieht: „ο“. hexdump -CDann wird Folgendes erzeugt:
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|
Das dritte Zeichen ist nun als UTF-8-Sequenz kodiert ce bf, bei der jedes Byte das 8. Bit gesetzt hat. Und das ist in diesem Fall Ihr Anzeichen für ein Problem. Beachten Sie auch, dass hexdump, das nur 7-Bit-ASCII dekodiert, das einzelne UTF-8-Zeichen nicht dekodiert und ..stattdessen zwei nicht druckbare Zeichen ( ) anzeigt.
Antwort2
Versuchen Sie, die Datei mit Nautilus umzubenennen, aber geben Sie den gewünschten Namen ein (nicht kopieren und einfügen). Dadurch sollten auf jeden Fall alle Sonderzeichen entfernt werden. Es kann sogar ein Leerzeichen nach/vor dem Dateinamen stehen, das für Sie unsichtbar, für das Betriebssystem und die Programme jedoch sichtbar ist. Normalerweise verwende ich mc, um mit wirklich seltsamen Dateinamen klarzukommen.
Antwort3
Haben Sie über das Vorhandensein eines Rootkits nachgedacht? Ich hatte einmal Zugriff auf eine Solaris-Maschine, auf der ein Rootkit installiert war. Dateien mit dem Namen „*01“ waren mit ls *01oder nicht sichtbar ls -altr, wurden aber mit einem angezeigt echo *01. Die Installation des Rootkits ls(und einer Reihe anderer ausführbarer Dateien) hatte sich geändert, sodass bestimmte Dateien und Prozesse unter den üblichen Umständen nicht angezeigt wurden. Ihre Beschreibung klingt sehr nach dem Rootkit, auf das ich gestoßen bin.
Antwort4
Falls jemand darüber stolpert und die anderen Antworten liest... SiekönnteSie müssen sich durch viele Reifen springen oder mit Platzhaltern zocken, wie es in einigen Antworten heißt, oder Sie verwenden einfach ls -b– ich erinnere mich an „binär“.
Die Tab-Vervollständigung in der Shell sollte das Zeichen automatisch in Anführungszeichen setzen, aber Sie können entweder etwas anderes als die Shell verwenden (wie Nautilus) oder den Shell-Escape-Anführungsstil verwenden, um lseine praktische vorangeführte Zeichenfolge für andere Befehle zu generieren. Ich habe dieses seltsame Dateibeispiel an anderer Stelle in einer anderen längeren Antwort verwendet, aber es ist auch hier relevant:
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'