Frage rsync 'kann nicht-leere Verzeichnisfehler nicht löschen, selbst mit der Option --force


Wenn Sie diesen Befehl ausführen:

$ sudo rsync -r --delete --force --checksum --exclude=uploads /data/prep/* /data/app/

Ich bekomme folgende Ausgabe:

cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins/uicolor
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source/plugins
cannot delete non-empty directory: html/js/ckeditor/_source
cannot delete non-empty directory: html/js/ckeditor/_samples
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor/yui
cannot delete non-empty directory: html/js/ckeditor/plugins/uicolor

Vom Lesen der man rsync Es war mein Eindruck, dass die --force Die Option würde rsync veranlassen, diese nicht leeren Verzeichnisse zu löschen, was das gewünschte Ergebnis ist.

Ref:

--force                 force deletion of dirs even if not empty

Wie kann ich den Befehl ändern, um die nicht leeren Verzeichnisse zu löschen?

Ich verwende rsync Version 3.0.8, auf Gentoo Base System Version 2.0.3, falls relevant.

Aktualisieren: Hinzugefügt sudo zu dem Befehl, um klarzustellen, dass dies kein Problem mit Dateiberechtigungen ist.


25
2018-02-05 15:30


Ursprung


Welches Dateisystem ist das Ziel? Ist das Dateisystem reparaturbedürftig? - Marcus Downing
Das Dateisystem ist ext3. Es ist möglich, dass das Dateisystem benötigt oder repariert werden kann. Krank fsck bei der nächsten Gelegenheit und update mit Ergebnissen. - tommarshall
Ich habe gerade fsckDas System und dieses Problem ist immer noch vorhanden. - tommarshall


Antworten:


Hast du versucht hinzuzufügen? --delete-excluded?

Wenn Sie ein Verzeichnis in Ihren ausgeschlossenen Ordnern auf der "Remote" -Seite löschen, rsync --delete löscht den ausgeschlossenen Ordner auf Ihrer "lokalen" Site nicht.


32
2018-03-18 13:08



Da war ein Ordner namens uploads in dem html/js/ckeditor/_source/plugins/uicolor/yui, html/js/ckeditor/_samples und html/js/ckeditor/plugins/uicolor/yui Verzeichnisse. Danke für Ihre Hilfe. - tommarshall


Hier sind mögliche Ursachen für dieses Problem:

(1) Dieser Fehler kann das Ergebnis der -b (- Sicherung) Option. Diese Option erstellt eine Sicherungskopie jeder gelöschten Datei, indem eine Tilde angehängt wird (~) auf seinen Dateinamen. (Dies verwirrte mich, da der Dateiname eindeutig eine Sicherung ist, aber der Verzeichnisname nicht, da Sie die Tilde nicht sehen können.)

Um zu überprüfen, ob dies der gleiche Fall ist, lies dein Zielverzeichnis auf der tiefsten Ebene und überprüfe, ob es eine Tilde (~) Enddatei gibt. Beachten Sie, dass diese an die Tilde angehängten Dateinamen in einigen gängigen Datei-Suchsystemen nicht sichtbar sind, sodass Sie sie möglicherweise nicht sehen können.

Um diesen Fall zu lösen, bevorzugen Sie die Option --backup-dir = DIR, zum Beispiel --backup-dir = .rsync_bak.

(2) Die Option --exclude kann dieselben Ergebnisse haben. Was möglicherweise in Ihrem Fall passiert. Das Mustersystem ist mächtig, kann aber irreführend sein. Wenn Sie beispielsweise --exclude = '* ~' schreiben, werden alle Tilde-Enddateien übersprungen, was genau wie im obigen Fall (1) resultiert.

von rsync man Seite:

Wenn das Muster mit einem / beginnt, ist es an einem bestimmten verankert   Spot in der Hierarchie der Dateien, sonst wird es gegen die verglichen   Ende des Pfadnamens

Si, wenn Sie --exclude = uploads schreiben, schließt dies alle Dateien mit dem Namen "updloads" bei irgendein Ebene Ihres Dateibaums.

Überprüfen Sie, ob in Ihren Verzeichnissen, die nicht gelöscht werden können, eine Datei namens "uploads" angezeigt wird.

Lösung wäre, "--exclude = uploads" zu "--exclude = uploads /" zu ändern


4
2018-05-10 11:21





In meinem Setup ((Quelle ist das Ubuntu-Format ext4, um den Western Digital-Typ fuseblk anzusteuern) funktioniert es mit:

rsync -a -v --progress --modify-window=1 -c -b -i -s -m --del -vv --ignore-errors --chmod=ugo=rwx --delete --delete-excluded  --exclude='*~'  --exclude='.*' --backup-dir=.rsync_bak /home/test /media/user/usbHDD

0
2018-01-04 19:30



Welcher Teil löst das Problem tatsächlich? - Michael Hampton♦


Ein Verzeichnis muss leer sein, damit Sie es löschen können, das Dateisystem benötigt das normalerweise.

Also normalerweise rsync oder rm würde zuerst alle Inhalte rekursiv löschen und erst dann das jetzt leere Verzeichnis löschen.

Wenn der aktuelle Benutzer nicht der Besitzer aller Dateien ist, können Sie die Dateisystemberechtigungen nicht löschen. Da sie nicht entfernt werden, wird das Verzeichnis nicht geleert und das Löschen schlägt fehl.

Meine erste Vermutung wäre, dass einige Dateien in diesem Verzeichnis im Besitz eines anderen Benutzers sind, z. die Apache oder niemand Benutzer.


-1
2018-02-05 15:52



Vielen Dank. Die Dateien in den Verzeichnissen gehören zwar einem Benutzer innerhalb der Apache-Gruppe, aber ich habe gerade versucht, diesen Befehl als diesen Benutzer auszuführen und habe die gleichen Fehler bekommen. - tommarshall
Wenn es sich um ein Problem mit Dateiberechtigungen handelt, würde ich erwarten, den gleichen Befehl wie bei 'sudo' auszuführen, um das Problem zu lösen, aber das ist nicht der Fall. Bitte korrigieren Sie mich jedoch, wenn ich mich irre. - tommarshall
Wenn Sie den Befehl als root ausführen, sollten Sie die meisten Berechtigungsprobleme umgehen, ja. (wahrscheinlich, wo das immer noch fehlschlagen würde ist auf einem NFS-Mount, um eine, eine unveränderliche Datei eine andere zu nennen) Eine einfache Überprüfung mit ls -la um zu sehen, warum das Verzeichnis immer noch nicht leer ist. lsattr zeigt unveränderliche Dateien an. - HBruijn
Danke für die zusätzlichen Informationen lsattr Aus einem der aufgeführten Verzeichnisse gibt Folgendes aus: --------------- ./assets (Nein ich Flag), und die Datei ist nicht auf einem NFS-Mount. Gibt es noch andere Gründe, warum der Befehl mit sudo immer noch fehlschlagen könnte? - tommarshall
Gibt es irgendwelche symbolischen Links oder nur echte Dateien? - Marcus Downing