Bonjour,
mon script lance sous root la commande rsync suivante:
sudo rsync -auAHXi --log-file=/home/ADMIN/ADMIN_clevo/BKP/log/23_04_29-184053.log --dry-run --delete --force --exclude-from=/usr/local/etc/exclude_rsync_clevo_sur_Samsung.txt / /media/laguilde/Samsung_2T_USB3
Je ne comprends pas pourquoi rsync refuse l’effacement de répertoires non-vides.
salut
donnes-nous les messages
mais dans un premier temps:
–archive, -a archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
Bonjour, merci pour votre intérêt
je n’ai pas réussi à reproduire ce comportement (sans rien modifier… je crois).
Le message titre se répètait pour un certain nombre de répertoires (3800 !)
Que souhaitez vous me dire à propos de l’option -a ?
Ce comportement est contemporain du problème plus mystérieux, l’effacement du répertoire boot, qui a mis en panne mon système habituel de travail (Buster) :
PS
en relisant la doc de rsync, j’ai pu voir que l’option –force est sans effet sur –delete
Je suppose qu’il faut écrire des règles d’exclusion…
-a interdit AXUNH donc ta commande rsync -auAHXi est en fait rsync -au
et a = rlptgoD
donc ta commande rsync -auAHXi est en fait rsync -urlptgoD
soit
--update, -u skip files that are newer on the receiver
--recursive, -r recurse into directories
--links, -l copy symlinks as symlinks
--perms, -p preserve permissions
--times, -t preserve modification times
--group, -g preserve group
--owner, -o preserve owner (super-user only)
--devices preserve device files (super-user only)
--specials preserve special files
et si tu mets
–dry-run, -n perform a trial run with no changes made
aucun changement n’est fait
PS ( les infos viennent du man )
mais il faut que tu nous montrer le message qui dit que le dossier refuse d’être détruit, avec le contenu et les priorités.
Merci de vous intéresser à mon problème,
Je n’ai pas compris que rsync -a interdisait ces autres options, mais seulement qu’elle ne les incluait pas, contrairement aux option rlptgoD dont elle serait un simple raccourci
( archive mode is -rlptgoD [is] not -A,-X,-U,-N,-H ).
J’utilise très habituellement cet ensemble d’options, et je ne crois pas qu’elles aient été mangées, mais je ne suis évidemment pas sur.
PS
J’utilise fréquemment setfattr (dans un script), et je viens de vérifier que ces attributs sont biens sauvegardés sur une sauvegarde rsync précédente. Ce qui me laisse penser que mon interprétation serais la bonne.
EDIT
le script réalise essentiellement la commande suivante:
setfattr -n user.comment -v « $commentaire » « $fichier »
pour éditer un commentaire pour un fichier
et lu avec un autre script qui utilise:
getfattr -Rn ‹ user.comment › « $fichier »
quand j’ai créé ces scripts, je les ai publié ici:
https://www.joseph-tux.fr/Commenter-ses-fichiers-en-ligne-de-commande?lang=fr
mais ils ont certainement été modifiés plusieurs fois depuis. Ça fait si longtemps…
pour lister tous les fichiers avec leurs commentaires.
tu as peut être raison j’ai parlé un peu vite, je vérifie
…un peu plus tard…
j’ai fait plein de tests avec et sans -H mais je ne vois pas de différence 
je sais juste que pour grsync en français, -H s’appelle copier les liens physiques tels quels
À première vue, mes liens physiques sont bien archivés tels quels (avec -aH)
Le message complet est dans le titre de ce fil, répété un grand nombre de fois
Les dossiers/fichiers ne seraient pas encours d’utilisation par un process ? un lsof sur un répertoire/file devraient t’indiquer si c’est le cas.
Merci Clochette
OK, je testerai cette proposition si je retrouve ce comportement. C’est une possibilité.