it-swarm.com.de

Es wurde versucht, das Verzeichnis mit "rm -rf" zu löschen, es wird jedoch die Meldung angezeigt, dass es nicht leer ist

Ich habe versucht, ein Verzeichnis mit "rm -rf" zu löschen und erhalte die Meldung "Directory not empty":

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

Wenn ich dasselbe mit Finder versuche (den Ordner in den Papierkorb ziehen), erhalte ich die Meldung

Der Vorgang kann nicht abgeschlossen werden, da das Element "leeres_Verzeichnis" verwendet wird.

Ich habe versucht, xattr -d com.Apple.quarantine zu machen, rein aus Aberglauben, aber es hat nichts gebracht.

Ein wahrscheinlich wichtiger Kontext ist, dass sich dieses Verzeichnis ursprünglich in einem Verzeichnis befand, das durch einen Befehl "make clean" gelöscht werden sollte, den ich vor dem Sperren des Terminals für mich ausgegeben hatte, wonach etwas mehr als die Hälfte der anderen Programme, über die ich verfügte Laufen auch gesperrt, einschließlich Skype, und schließlich das Betriebssystem selbst. Schließlich musste ich den Computer neu starten, indem ich die Ein-/Aus-Taste gedrückt hielt.

Bearbeiten zum Hinzufügen: Eine weitere wichtige Information, die ich weggelassen habe, war, dass dies in einem verschlüsselten Ordner à la encfs geschah. Ich konnte den entsprechenden Ordner in der verschlüsselten Seite der Dinge aufspüren und dort löschen. Ich weiß immer noch nicht, warum ich es nicht von der entschlüsselten Seite der Dinge tun konnte, wie ich es normalerweise tue. Ich werde dies vorerst unbeantwortet lassen, falls jemand eine gute Antwort darauf hat.

28
Ben Hocking

Starten Sie Ihren Computer neu und führen Sie rmdir(1) erneut aus.

$ rmdir -r empty_directory/

Wenn das nicht funktioniert, versuchen Sie Folgendes:

$ rm -rf empty_directory/

Wenn es immer noch nicht funktioniert, unter der Annahme, dass in OS X lsof(8) vorinstalliert ist, geben Sie Folgendes ein:

$ lsof +D empty_directory/

Dies sollte anzeigen, ob Dateien in diesem Verzeichnis von Programmen verwendet werden. Ich denke, dass das HFS + -Dateisystem das Löschen der verwendeten Dateien nicht erlaubt. Wie auch immer, killall(1) alle ausführbaren Dateien, die dieses Verzeichnis verwenden, oder alle darin versteckten Dateien. Es ist wahrscheinlich, dass Finder eine versteckte Datei im Verzeichnis empty_directory verwendet, um Einstellungen für die Ordneransicht zu speichern. Hoffe das hilft.

P.S .: Um herauszufinden, ob lsof(8) installiert ist, geben Sie Folgendes ein:

$ lsof

Wenn die Ausgabe so aussieht, ist lsof(8) auf Ihrem System installiert.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Suchen Sie in diesem Verzeichnis nach versteckten und verschlüsselten Dateien oder Verschlüsselungsschlüsseldateien. Dies könnte der Schuldige sein.

9
Jonathan Reno

Das Reparieren der Festplatte mit dem Festplatten-Dienstprogramm hat dieses Problem für mich behoben.

3
Shlok Datye

Ich bin auf genau diesen Fehler gestoßen, als ich auch versucht habe, ein Verzeichnis zu entfernen (rm -r dirname). Ich habe bereits alle Vorschläge ausprobiert, die ich hier gelesen habe, bevor ich diesen Thread gesucht und gefunden habe. Ich weiß nicht, ob es irgendwelche zusätzlichen Punkte gegeben hat, die von der ursprünglichen Frage unbeabsichtigt unangemeldet geblieben sind, aber in meinem Fall war die Wurzel des Problems und die Lösung:

  • das betreffende Verzeichnis befand sich auf einer im Netzwerk eingebundenen Festplatte

  • jeder ls Versuch vom Finder oder der Befehlszeile zeigte nur . und ..

  • Ich habe mich über den Befehl ssh beim Netzwerkfestplattenserver angemeldet und dort den ls -al überprüft. Das Ergebnis zeigte zusätzlich zu . und .. mehrere .__filename Elemente mit erweiterten Sicherheitsinformationen (d. H. + an den Modus angehängt).

Ich glaube, dies sind oder ähneln Dateien, die ich vor Jahren unter Mac OS X zum ersten Mal entdeckt habe, als ich cp -R, tar oder cpio zum Archivieren oder Verschieben von Dateigruppen verwendete. Ich hatte damals festgestellt, dass sie verwendet wurden, um einige Dateieigenschaften nach dem Verschieben ordnungsgemäß zurückzusetzen - möglicherweise uid/gid, mode, acls, mtime/utime/ctime usw .; Ich bin mir nicht sicher - Eigenschaften, die zuvor nicht korrekt zurückgesetzt wurden (ich erinnere mich, dass OSX früher mvmac- und cpmac-Befehle enthielt, um das Problem zu umgehen) bevor diese .__filename Arten von Dateien auftauchten, wenn die üblichen Formen von cp, tar usw. verwendet wurden).

Ich hatte noch nie Probleme beim Löschen dieser Dateien, wenn sie auf ein internes, USB- oder Firewire-Laufwerk geschrieben wurden. Dies war das erste Mal, dass ich sie auf einer Netzwerkfestplatte gefunden hatte. Von der Client-Seite des Mounts völlig unerkennbar, aber von der Server-Seite aus in jeder Hinsicht normal.

rm -rf dirname von einem Login auf dem Netzwerkfestplattenserver hat das Verzeichnis zusammen mit seinem Inhalt ordnungsgemäß entfernt.

Es gibt also eine andere Antwort für das, was es wert ist. Eine weitere mögliche Lösung für dieses Problem, wenn es für jeden in Verbindung mit einer Netzwerkfestplatte angezeigt werden soll.

2
Ken

Wenn dies passiert und Sie sicher sind, dass Sie alles löschen möchten, sollten Sie versuchen, Sudo rm -rf directory/ zu verwenden.

2
m1.

Versuchte alle Antworten hier ohne Ergebnisse. Ich konnte das Verzeichnis jedoch mit dem Befehl mv beiseite schieben, wodurch ich fortfahren konnte.

1
Jeremy Ninnes

Die einzige Lösung, die für mich funktioniert hat, war von https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do :

Verschiebe sie nach/tmp und starte neu.

Die anderen Optionen, die ich ausprobiert habe, waren:

  • Festplatten-Dienstprogramm - Erste Hilfe.
  • lsof +D bad_file zeigte keine Ausgabe.
  • Sudo rm -rf
  • Booten in Einzelbenutzerterminal und rm -rf.
1
Joe

Zum Wohle der Leser:

Passen Sie in einem solchen Fall auf rm -rf auf! Wenn es sich um eine Netzwerkfreigabe handelt, kann dies an anderer Stelle zu Problemen führen! Sie wurden gewarnt!

In fast allen Fällen, wenn eine directory leer zu sein scheint, verwenden Sie rmdir directory oder vielleicht Sudo rmdir directory. Verwenden Sie nicht rm (oder del unter Windows). Wenn dies nicht funktioniert, müssen Sie herausfinden, was diese Anforderung blockiert, das beheben und dann die rmdir wiederholen.

Bitte beachten Sie, dass ich OS-X nicht kenne, aber ich denke, dass die Dinge dort dem Unix/BSD-Verhalten sehr ähnlich sind.

Es ist sehr wahrscheinlich, dass das fragliche Verzeichnis nur ein Einhängepunkt (aus dem encfs) war oder sich auf einem Einhängepunkt befand, der readonly wurde oder in einigen stecken blieb falscher Zustand (der das Entfernen des Verzeichnisses verhinderte). Wenn Sie jetzt das Entfernen des Verzeichnisses erzwingen, können sehr schlimme Dinge passieren.

Im guten Fall war das Verzeichnis wirklich leer, so dass das Entfernen (Zerstören des Reiters usw.) keinen weiteren Schaden anrichtete. Im schlimmen Fall war es nicht leer, es schien nur so zu sein, was bedeutet, dass Sie etwas weggeworfen haben, das Sie vielleicht nicht töten wollten. Dies hängt alles vom Mount-Typ, den verwendeten Treibern usw. ab.

Wenn die Dinge einigermaßen gut implementiert sind, sollte normalerweise nichts Schlimmes passieren. Dies ist jedoch nicht der Normalfall. Die Dinge befinden sich bereits in einem seltsamen Zustand, was bedeutet: Etwas stimmt nicht, also versuchen Sie besser nicht, es noch weiter zu verwechseln! Wenn etwas geknackt ist, kann eine falsche Berührung es zerbrechen.

Wenn Sie beispielsweise eine Race-Bedingung für eine Netzwerkfreigabe erfüllen, werden durch Ihren rm -rf möglicherweise Daten entfernt, die nur von einer anderen Person auf die Freigabe kopiert wurden.

Es wird jedoch garantiert, dass rmdir nicht nur wirklich leere Verzeichnisse entfernt, sondern auch niemals Schaden anrichtet. Dies gilt sogar für NFS, da NFS nur für mkdir und rmdir ein wirklich atomares Verhalten garantiert, aber nirgendwo anders.

Zu Ihrer Information:

Sie können einen Mountpunkt mit dem Tool mountpoint directory erkennen. Alternativ können Sie sich die Ausgabe von mount ansehen und versuchen, Ihre Reittiere dort zu finden. Aber Vorsicht, zumindest unter Linux könnte das liegen. Die Verwendung des Dienstprogramms mountpoint ist zuverlässiger, aber weniger praktisch.

In diesem Fall haben Sie den Einhängepunkt gefunden. Sie können ihn aushängen und dann das Verzeichnis entfernen. Dies ist die folgende Reihenfolge:

umount directory rmdir directory

Verwenden Sie bei Bedarf wie gewohnt Sudo.

Anmerkungen:

  • Netzwerkfreigaben können rmdir (und alles andere) aufgrund von Zugriffsrechten verweigern.

  • Defekte Dateisysteme können je nach Fehlerstrategie rmdir verweigern. Vielleicht werden Sie in diesem Fall eine vernünftige Nachricht sehen, vielleicht auch nicht.

  • Unter Linux (und wahrscheinlich jedem modernen Betriebssystem) können Sie den Zugriff auch auf andere Weise einschränken (z. B. nur lesbares Mounten, Funktionen wie in SeLinux usw.). Dies bedeutet dann, dass Sie nicht sehen, dass es sich um einen Einhängepunkt handelt, und Sie sehen nichts Falsches, aber es funktioniert einfach nicht. In diesem Fall müssen Sie nach einem anderen Grund suchen, und es kann sehr tief im Betriebssystem vergraben sein. Es hängt vom jeweiligen Tool ab, ob eine sinnvolle Fehlermeldung angezeigt wird. Vielleicht schau auch mal in das syslog/kernel-log wie dmesg unter Linux (sorry, ich kenne das OS-X Äquivalent nicht).

  • Beachten Sie, dass die obligatorische Dateisperrung auch eine Quelle sein kann. Während dies unter Windows normal ist, ist es normalerweise nicht der Normalfall für Unix und ich habe es für Verzeichnisse nie gehört. Obligatorische Dateisperren werden von POSIX abgedeckt, sind jedoch optional.

  • In solchen Fällen befindet sich das betreffende Verzeichnis häufig auf einem anderen Dateisystem als gedacht. Mit dem Befehl df directory können Sie herausfinden, welche (ich denke, dasselbe unter OS-X).

  • Sie können das Verzeichnis mit Tools wie stat oder statfs genauer untersuchen. Dies ist jedoch für normale Menschen ein wenig zu niedrig, und solche Tools sind für normale Benutzer häufig gut versteckt.

  • Verzeichnisse können Dateien mit lustigen Namen haben. Wie eine Datei, die die Ausgabe des Terminals sofort löscht und so aussieht, als wäre sie nicht vorhanden. Versuchen Sie etwas wie ls -al | less oder verwenden Sie etwas wie MidnightCommander mc.

Es gibt eine Menge anderer Möglichkeiten, einschließlich Bugs, Haxors, Aliens oder vielleicht exotischeren Dingen wie Feen. Aber normalerweise ist es nicht ratsam, dort nachzuschauen, sondern zuerst zu versuchen, den Fehler an Ihrer Seite zu finden, weil "errare humanum est".

1
Tino

Dies könnte auch ein Fall sein, den ich gerade gelöst habe, in dem sich ein defekter Symlink auf der Serverseite befand und der für den Client über CIFS nicht sichtbar war. Der Symlink füllte ein nicht leeres Verzeichnis, aber der Client konnte den Symlink nicht sehen oder angeben, um das Verzeichnis zu löschen, bevor die Verknüpfung zum Verzeichnis aufgehoben wurde. Da es unsichtbar war, erzeugte es dieses Paradox, bei dem es von der Client-Seite aus leer war, aber auf Anfrage von rm "nicht leer" war. Wenn Sie über SSH-Zugriff auf den Server verfügen, versuchen Sie es mit einer Shell, und prüfen Sie, ob das Verzeichnis wirklich leer ist oder ob die Symlinks möglicherweise beschädigt sind. Ich konnte das auf einem Drobo5N machen und es hat meinen Hintern gerettet.

1
Jon

Versuchen Sie, dieses Verzeichnis unter Windows zu öffnen. Unter Mac OS wird möglicherweise etwas nicht angezeigt. Ich hatte nach einer Reihe von Kopiervorgängen zwischen Mac und Win PC ein ähnliches Problem: Das Verzeichnis war selbst im Terminal leer, aber unter Windows fand ich eine versteckte Windows-Datei, sodass ich das Verzeichnis erfolgreich von dort entfernte.

0
contre_force