rsync "impossibile eliminare directory non vuote", anche con l'opzione --force

28

Quando si esegue questo comando:

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

Sto ottenendo il seguente output:

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

Dalla lettura man rsyncè stata la mia impressione che l' --forceopzione dicesse a rsync di eliminare queste directory non vuote, che è il risultato desiderato.

Rif:

--force                 force deletion of dirs even if not empty

Come posso modificare il comando per eliminare le directory non vuote?

Sto usando rsync versione 3.0.8, su Gentoo Base System versione 2.0.3, nel caso sia rilevante.

Aggiornamento: aggiunto sudoal comando per chiarire che questo non è un problema di autorizzazioni di file.

— tommarshall
fonte

Quale filesystem è la destinazione? Il filesystem ha bisogno di essere riparato?

— Marcus Downing,

Il file system è ext3. È possibile che il filesystem potrebbe essere necessario o riparato. Sarò fsckalla prossima occasione e aggiornerò con i risultati.

— Tommashall,

Ho appena avuto fsckil sistema e questo problema è ancora presente.

— Tommashall,

39

Hai provato ad aggiungere --delete-excluded?

Se si elimina una directory nelle cartelle escluse sul lato "remoto", rsync --deletenon verrà eliminata la cartella esclusa sul sito "locale".

— Martin Höger
fonte

C'era una cartella chiamata uploadsnei html/js/ckeditor/_source/plugins/uicolor/yui, html/js/ckeditor/_samplese html/js/ckeditor/plugins/uicolor/yuile directory. Grazie per l'aiuto.

— Tommashall,

se si utilizza --delete-excludedma si desidera comunque escludere determinati file / directory dall'eliminazione, è possibile inserire questi file / directory --filter 'protect some_dir/', ad esempio:rsync -ac --delete --delete-excluded --exclude '*.html' --filter 'protect .git/' . /target/destination/

— alexandre1985

6

Ecco le possibili fonti di questo problema:

(1) Questo errore può essere il risultato dell'opzione -b (--backup). Questa opzione creerà un backup di ogni file eliminato, aggiungendo una tilde ( ~ ) al suo nome file. (Questo mi ha confuso, poiché il nome del file è chiaramente un backup, ma il nome della directory non lo è, poiché non è possibile vedere la tilde.)

Per verificare se questo è lo stesso caso, leggi la directory di destinazione al livello più profondo e controlla se esiste un file finale tilde (~). Nota che questi nomi di file aggiunti in tilde sono quindi invisibili in alcuni comuni sistemi di esplorazione dei file, quindi potresti non vederli.

Per risolvere questo caso, preferisci l'opzione --backup-dir = DIR, ad esempio --backup-dir = .rsync_bak.

(2) L'opzione --exclude può avere gli stessi risultati. Che forse sta succedendo nel tuo caso. Il sistema di schemi è potente, ma può essere fuorviante. Ad esempio se scrivi --exclude = '* ~', questo salterà tutti i file di fine tilde, risultando esattamente come nel caso (1) sopra.

dalla pagina man di rsync:

se il modello inizia con un / allora è ancorato a un punto particolare nella gerarchia dei file, altrimenti viene confrontato con la fine del nome percorso

Sì, se scrivi --exclude = uploads, questo escluderà tutti i file denominati "updloads", a qualsiasi livello dell'albero dei tuoi file.

Controlla se c'è un file chiamato "uploads" all'interno delle tue directory impossibili da eliminare.

La soluzione sarebbe cambiare "--exclude = uploads" in "--exclude = uploads /"

— user3586623
fonte

0

Nella mia configurazione ((il sorgente è in formato Ubuntu ext4 per target fuseblk di tipo Western Digital) funziona con:

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

— Legalmente
fonte

2

Quale parte di questo risolve effettivamente il problema?

— Michael Hampton

0

Utilizzare le regole nei file di filtro anziché --exclude. Questi consentono di contrassegnare gli esclusivi come "persihable", che consente di eliminare le directory non vuote che contengono file esclusi.

Vedi questa risposta per i dettagli.

— mivk
fonte

-1

Una directory deve essere vuota per poterla eliminare, normalmente il file system lo richiede.

Pertanto normalmente rsynco rmeliminerebbe in modo ricorsivo tutto il contenuto prima e solo successivamente eliminerà la directory ora vuota.

Se l'utente corrente non è il proprietario di tutti i file, le autorizzazioni del file system non ti consentiranno di eliminare tali file. Poiché non verranno rimossi, la directory non viene svuotata e l'eliminazione non riuscirà.

La mia prima ipotesi sarebbe che alcuni file in quella directory siano di proprietà di un altro utente, ad esempio l'apache o nessuno.

— HBruijn
fonte

Grazie. I file all'interno delle directory sono effettivamente di proprietà di un utente all'interno del gruppo apache, tuttavia ho appena tentato di eseguire questo comando come quell'utente e ho riscontrato gli stessi errori.

— Tommashall,

Inoltre, se si trattasse di un problema con le autorizzazioni dei file, mi aspetterei di eseguire lo stesso comando di "sudo" per risolvere il problema, ma non è così. Tuttavia, per favore correggimi su questo se sbaglio.

— Tommashall,

1

L'esecuzione del comando come root dovrebbe superare la maggior parte dei problemi di autorizzazione, sì. (probabilmente il posto in cui ciò fallirebbe è su un mount nfs per nominarne uno, un file immutabile un altro) Un semplice controllo ls -laper vedere perché la directory non è ancora vuota. lsattrvisualizzerà file immutabili.

— HBruijn,

Grazie per le informazioni aggiuntive, tuttavia lsattrda una delle directory elencate viene visualizzato quanto segue: --------------- ./assets(nessun flag i) e il file non si trova su un mount nfs. Ci sono altri motivi per cui potresti pensare al motivo per cui il comando fallirebbe comunque con sudo?

— Tommashall,

Ci sono link simbolici o solo file reali?

— Marcus Downing,