Wie lösche ich dieses nicht löschbare Verzeichnis?

Ich habe eine beschädigte tar-Datei entpackt und es geschafft, ein Verzeichnis zu finden, das ich nicht löschen kann. Wenn ich versuche, es zu löschen, kann es anscheinend nicht gefunden werden, lszeigt aber , dass es sowohl mit Bash als auch mit Python vorhanden ist Ähnliches Verhalten, außer dass ich gleich nach dem Versuch, es mit zu löschen rm -rf, lsbeschwere, dass es es nicht finden kann, und es es dann auflistet (siehe weiter unten rm -rf). Der findBefehl zeigt an, dass die Datei vorhanden ist, mir fällt jedoch keine Möglichkeit zum Löschen ein.
Hier sind meine Versuche:

Hier sehen Sie beide lsund findstimmen zu, dass wir ein Verzeichnis haben,

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -print0  
./mikeaâcnt 

Ich kann es aber nicht löschen:

rl]$ find -maxdepth 1 -type d -empty -print0 |  xargs -0 rm -f -v 
rm: cannot remove `./mikeaâ\302\201\302\204cnt': Is a directory
rl]$ ls
mikeaâ??cnt

Ich kann cdes aber und es ist leer:

rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ pwd
.../rl/mikeaâcnt


mikeaâ^Á^Äcnt]$ cd ../
rl]$ ls
mikeaâ??cnt

siehe unten, das ist keine einfache Datei, sondern ein Verzeichnis. Außerdem lsverhält es sich komisch, wenn rm -rf es sagt, dass es die Datei nicht finden kann, und listet sie dann direkt danach auf:

rl]$ rm mikeaâ^Á^Äcnt/
rm: cannot remove `mikeaâ\302\201\302\204cnt/': Is a directory
rl]$ rm -rf  mikeaâ^Á^Äcnt/
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ 

Das ist also der Versuch mit Python, die Datei wird gefunden, aber der Name kann nicht als Name verwendet werden, der gelöscht werden kann:

rl]$ python 
Python 2.6.6 (r266:84292, Jul 10 2013, 22:48:45) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import shutil
>>> os.listdir('.')
['mikea\xc3\xa2\xc2\x81\xc2\x84cnt']
>>> shutil.rmtree(os.listdir('.')[0] )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/shutil.py", line 204, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/usr/lib64/python2.6/shutil.py", line 202, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: 'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

Selbst wenn ich die Tab-Vervollständigung verwende, ist der Name, den es aufnimmt, nicht verwendbar:

rl]$ rm -rf mikeaâ^Á^Äcnt 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Unter Verwendung des Namens, den Python mit Bash anzeigt, erhalte ich Folgendes:

rl]$ rm -rf "mikea\xc3\xa2\xc2\x81\xc2\x84cnt"
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Kann ich irgendetwas tun, um dieses korrupte Verzeichnis loszuwerden? Das zugrunde liegende Dateisystem (NFS) scheint funktionsfähig zu sein, und es wurden keine weiteren Probleme gemeldet. Bis zur Beschädigung der tar-Datei hatte ich keine derartigen Probleme.

BEARBEITEN: Hier wird die findeigene -execOption zum Anrufen verwendetrm

rl]$ find -maxdepth 1 -type d -empty -exec rm -f {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

aber die datei ist immer noch da ( lsbeschwert sich, dass sie nicht gefunden werden kann, zeigt sie dann aber trotzdem an)

2. EDIT:

rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} \;
find: `./mikeaâ\302\201\302\204cnt': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Das Verhalten ist noch unverändert, die Datei noch vorhanden

3. EDIT:

rl]$ ls
mikeaâ??cnt
rl]$ find -maxdepth 1 -type d -empty -exec rm -rf {} + 
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Der Name scheint mehr zu bedeuten, als sich mikeaâcntdie Ausgabe des Python-Versuchs mikea\xc3\xa2\xc2\x81\xc2\x84cntund den folgenden Screenshot anzusehen:

4. BEARBEITUNG: Dies ist der Versuch mit einem Platzhalter:

rl]$ echo * 
mikeaâcnt
rl]$ echo mike* 
mikeaâcnt
rl]$ rm -rf mike*
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

und mein Gebietsschema:

rl]$  locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

5. Änderung:

rl]$ ls -i 
ls: cannot access mikeaâcnt: No such file or directory
? mikeaâ??cnt

aber auch das verhalten hat sich geändert, jetzt lsund cd mach das:

rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt 
mikeaâcnt: No such file or directory.

Dies geschah nach den Löschversuchen. Ich denke, es könnte sich um NFS-Probleme handeln, wie in einer der Antworten hier von vinc17 vorgeschlagen.

6. EDIT: Dies ist die Ausgabe von lsofundls -a

rl] $ / usr / sbin / lsof mikeaâ ^ Á ^ Äcnt lsof: Statusfehler auf mikeaâ \ xc2 \ x81 \ xc2 \ x84cnt: Keine solche Datei oder Verzeichnis

oben ist falsch, hier ist der richtige lsofAufruf: (rl ist das übergeordnete Verzeichnis)

rl]$ /usr/sbin/lsof | grep mike | grep rl 
tcsh      11926   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14733   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14734   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
grep      14735   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
lsof      14736   mike  cwd       DIR   0,33     4096 19569249 /home/mike/mish/rl
rl]$ 

rl]$ ls -a
ls: cannot access mikeaâcnt: No such file or directory
.  ..  mikeaâ??cnt

7. Bearbeiten: Verschieben funktioniert nicht, (ich habe es vor all dem versucht, aber ich habe die Ausgabe nicht gespeichert ), aber es hat das gleiche Problem wie lsund rmmit der Datei.

8. BEARBEITEN: Dies verwendet die Hex-Zeichen wie vorgeschlagen:

 rl]$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.
rl]$ rmdir $'mikea\6d69\6b65\61c3\a2c2\81c2\8463\6e74\0acnt' 
rmdir: failed to remove `mikea\006d69\006b651c3\a2c2\\81c2\\8463\006e74': No such file or directory
rl]$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
rl]$

9. Edit: für den statBefehl:

 rl]$ stat  mikeaâ^Á^Äcnt 
stat: cannot stat `mikeaâ\302\201\302\204cnt': No such file or directory
 rl]$

Es scheint sogar wahrscheinlicher, dass bei der gesamten Ausgabe ein Fehler oder ein anderes NFS-Fehlverhalten vorliegt, wie in den Kommentaren vorgeschlagen.

Edit 10: Dies ist eine direkte Ausgabe in einer Liste, da sie so groß ist, die Ausgabe oder diese beiden Befehle:

strace -xx rmdir ./* | grep -e '-1 E'`
strace -xx -e trace=file ls -li`

https://gist.github.com/mikeatm/e07fa600747a4285e460

Edit 11: Also vor dem oben genannten habe rmdirich gemerkt, dass ich cdin das Verzeichnis konnte, aber nach dem rmdirkonnte ich nicht cdwieder, ähnlich wie gestern. Die .und .. Dateien waren vorhanden:

rl]$ ls
mikeaâ??cnt
rl]$ cd mikeaâ^Á^Äcnt/
mikeaâ^Á^Äcnt]$ ls
mikeaâ^Á^Äcnt]$ ls  -a
.  ..
mikeaâ^Á^Äcnt]$ cd ../

Letzte Änderung: Ich habe einen lokalen Administrator gesehen, und es wurde behoben, indem ich mich beim Server selbst anmeldete und von dort aus löschte. Die Erklärung von ihnen ist, dass es ein Problem mit Zeichensätzen im Namen sein könnte, die unpassend sind.

Der folgende Auszug aus diesem Aufsatz erklärt möglicherweise, warum dieses Verzeichnis nicht gelöscht werden darf:

Für NFSv4 müssen alle Dateinamen mit UTF-8 über das Netzwerk ausgetauscht werden. Die NFSv4-Spezifikation RFC 3530 besagt, dass Dateinamen in Abschnitt 1.4.3 mit UTF-8 codiert werden sollten: „In einer kleinen Abweichung werden Datei- und Verzeichnisnamen mit UTF-8 codiert, um die Grundlagen der Internationalisierung zu behandeln.“ Derselbe Text finden Sie auch im neueren Abschnitt 1.7.3 von NFS 4.1 RFC (RFC 5661). Der aktuelle Linux NFS-Client übergibt Dateinamen einfach direkt und ohne Konvertierung vom aktuellen Gebietsschema zu und von UTF-8. Die Verwendung von Nicht-UTF-8-Dateinamen kann auf einem System mit einem Remote-NFSv4-System ein echtes Problem darstellen. Jeder NFS-Server, der der NFS-Spezifikation folgt, muss Nicht-UTF-8-Dateinamen ablehnen. Wenn Sie also sicherstellen möchten, dass Ihre Dateien tatsächlich von einem Linux-Client auf einem NFS-Server gespeichert werden können, müssen Sie derzeit UTF-8-Dateinamen verwenden. Mit anderen Worten,

UTF-8 ist ein längerfristiger Ansatz. Systeme müssen UTF-8 sowie die vielen älteren Codierungen unterstützen, damit die Benutzer Zeit haben, auf UTF-8 umzusteigen. Um "UTF-8 überall" verwenden zu können, müssen alle Tools aktualisiert werden, um UTF-8 zu unterstützen. Vor Jahren war dies ein großes Problem, aber seit 2011 ist dies im Wesentlichen ein gelöstes Problem, und ich denke, dass die Flugbahn für diese wenigen nachlaufenden Systeme sehr klar ist.

Nicht alle Byte-Sequenzen sind für UTF-8 zulässig, und Sie möchten nicht wissen, wie sie angezeigt werden sollen. Wenn der Kernel diese Einschränkungen durchführt und sicherstellt, dass nur UTF-8-Dateinamen zulässig sind, ist dies kein Problem. Alle Dateinamen sind UTF-8-legal. Markus Kuhns utf8_check C-Funktion kann schnell feststellen, ob eine Sequenz UTF-8-gültig ist.

Das Dateisystem sollte erfordern, dass Dateinamen einem bestimmten Standard entsprechen, nicht wegen eines bösen Bedürfnisses, Menschen zu kontrollieren, sondern einfach, damit die Namen zu einem späteren Zeitpunkt immer korrekt angezeigt werden können. Das Fehlen von Standards erschwert die Arbeit für die Benutzer und erleichtert sie nicht. Das Dateisystem erzwingt jedoch nicht, dass Dateinamen UTF-8 sind, sodass es leicht zu Datenmüll kommen kann.

Eine Möglichkeit, solche Dateien / Verzeichnisse zu löschen, ist die Verwendung der Inode-Referenz.

So finden Sie die Inodes für Elemente im aktuellen Verzeichnis:

ls -i
14813568 mikeaâcnt

Um dies zu löschen:

find . -inum 14813568 -delete

Sie sollten in der Befehlszeile keine Nicht-ASCII-Zeichen verwenden, da diese aus irgendeinem Grund nicht unbedingt dem Dateinamen entsprechen (Unicode bietet verschiedene Möglichkeiten, Buchstaben mit Akzenten auszudrücken). So etwas wie:

rm -rf mike*

sollte funktionieren, da der Dateiname direkt von der Shell generiert wird. Stellen Sie jedoch sicher, dass es nur eine Übereinstimmung gibt (bestätigen Sie dies echo mike*zuerst).

Wenn es cdfunktioniert, gibt es keinen Grund, warum rmoder lssollte ich sagen No such file or directory, dass das Problem möglicherweise auf Dateisystemebene liegt.

Hinweis: Verwenden Sie nicht, lsum festzustellen, ob ein Verzeichnis leer ist, sondern ls -a.

Das Verzeichnis kann weiterhin von einem anderen Prozess verwendet werden (auch wenn es sich um den CWD eines Prozesses handelt). IMHO, deshalb "existiert" es immer noch, kann aber zu Fehlern führen, zB mit ls; lsofSie erhalten möglicherweise einige Informationen, aber mit NFS müssen Sie herausfinden, auf welchem ​​Computer diese verwendet werden. Insbesondere bei NFS kann dies zu merkwürdigen Fehlern führen. ls -aim übergeordneten Verzeichnis können .nfs*in einigen Fällen Dateien / Verzeichnisse angezeigt werden.

Wenn du bekommst:

$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt

Ich vermute, dass die Datei aufgrund von NFS-Caching und / oder aufgrund der Verwendung durch einen anderen Prozess, jedoch ohne zugehörige Informationen, noch in der Verzeichnistabelle vorhanden ist. Wenn lsversucht wird, Informationen über die Datei selbst abzurufen, wird ein Fehler ausgegeben, da die Datei selbst nicht mehr vorhanden ist (sie befindet sich nur in der Verzeichnistabelle), daher der angezeigte Fehler. Anschließend wird lsder Dateiname ausgegeben, da er in der Verzeichnistabelle enthalten ist. Die Tatsache, dass Sie in einem Fall Fragezeichen haben, aber nicht in dem anderen Fall, ist auf einen Anzeigefehler von lsIMHO zurückzuführen (unabhängig von Ihrem Problem).

Ich habe persönlich anhand findder -execRichtlinie getestet :

$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$ 

Der Ordner wurde korrekt erstellt und korrekt entfernt.

Wie von @Igeorget hervorgehoben , gibt es eine noch einfachere Methode, wenn Sie GNU haben find:

$ find -maxdepth 1 -type d -empty -delete

Ich habe diesen Befehl auch getestet und er funktioniert ordnungsgemäß

Ich glaube, ich hatte das gleiche Problem. Ich habe das Problem früher mit einem Dateinamen von gesehen ☃. lsIn diesem Fall wurde die Datei als angezeigt â??, aber ich konnte sie mit löschen rm ☃.

Dies führte mich zu der folgenden Methode, um den falschen Namen in den richtigen Namen umzuwandeln:

Holen Sie sich zuerst die Bytes des Dateinamens:

$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a    mikea......cnt.

Dekodieren Sie diese Bytes dann als UTF-8, um die Unicode-Codepunkte zu erhalten. Verwenden Sie dazu die hexadezimale Eingabe dieser Website, beispielsweise: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (â)
U+0081 <control> character (&#x0081;)
U+0084 <control> character (&#x0084;)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Beachten Sie, dass diese alle unterhalb der Byte-Grenze liegen. Wir erhalten folgende Bytes:

6D 69 6B 65 61 E2 81 84 63 6E 74

Wenn wir diese Sequenz bei UTF-8 behandeln, erhalten wir:

U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (⁄)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character

Und so lautet Ihr Dateiname:, mikea⁄cntmit einem Bruchstrich anstelle eines normalen Schrägstrichs. Sie können diesen Namen jetzt an übergeben rmdir.

Nachdem Sie den korrekten Hex-Code für den Datei- / Ordnernamen erhalten haben (mit welcher Methode auch immer, kann ich wählen ls --show-control-chars | xxd), sollten Sie ein spezielles Konstrukt verwenden, um solche Zeichen zu adressieren, wenn Sie unter bash ausgeführt werden:

rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'

Ansonsten werden Backslashes wie Vanille-Backslashes behandelt.

Haben Sie versucht, rm -rf ./mikeaâcntoder rm -rf "./mikeaâcnt"oder einen absoluten Pfad zu verwenden? rmVersuchen Sie es auch statt rmdir ./mikeaâcnt.

Haben Sie versucht, die Inode dieser Datei zu erhalten mit stat:

stat mike*

Das sollte dir die Inode-Nummer (und andere Daten) geben, und dann könntest du versuchen, sie zu löschen.

Ich hatte ähnliche Probleme. Haben Sie Gnome, KDE oder eine Art Xwindow DM? Wenn Sie Ihren File Broser öffnen und die Datei von dort entfernen.

Es sollte funktionieren.

Ich würde gerne eine Lösung von der Kommandozeile aus sehen, aber in meinem Fall und nachdem ich viel Zeit damit verbracht habe, herauszufinden, wie man sie von der Kommandozeile entfernt, stellte ich fest, dass es so einfach ist, wie jede andere Datei von nautilus oder zu entfernen jeder andere dateiexplorer (wahrheit ich habe es nur mit nautilus versucht).