La suggestion d'utiliser ire_and_curses pose tar c <dir>
quelques problèmes:
- tar traite les entrées du répertoire dans l'ordre dans lequel elles sont stockées dans le système de fichiers, et il n'y a aucun moyen de changer cet ordre. Cela peut effectivement donner des résultats complètement différents si vous avez le "même" répertoire à différents endroits, et je ne connais aucun moyen de résoudre ce problème (tar ne peut pas "trier" ses fichiers d'entrée dans un ordre particulier).
- Je me soucie généralement de savoir si les numéros groupid et ownerid sont identiques, pas nécessairement si la représentation sous forme de chaîne du groupe / propriétaire est la même. Ceci est conforme à ce que fait par exemple
rsync -a --delete
: il synchronise pratiquement tout (moins xattrs et acls), mais il synchronisera le propriétaire et le groupe en fonction de leur ID, pas sur la représentation sous forme de chaîne. Donc, si vous avez synchronisé avec un système différent qui n'a pas nécessairement les mêmes utilisateurs / groupes, vous devez ajouter l' --numeric-owner
indicateur à tar
- tar inclura le nom de fichier du répertoire que vous vérifiez lui-même, juste quelque chose dont vous devez être conscient.
Tant qu'il n'y a pas de solution pour le premier problème (ou à moins que vous ne soyez sûr que cela ne vous affecte pas), je n'utiliserais pas cette approche.
Les find
solutions basées proposées ci-dessus ne sont pas non plus bonnes car elles n'incluent que des fichiers, pas des répertoires, ce qui devient un problème si la somme de contrôle doit garder à l'esprit les répertoires vides.
Enfin, la plupart des solutions suggérées ne trient pas de manière cohérente, car le classement peut être différent d'un système à l'autre.
Voici la solution que j'ai trouvée:
dir=<mydir>; (find "$dir" -type f -exec md5sum {} +; find "$dir" -type d) | LC_ALL=C sort | md5sum
Remarques sur cette solution:
- Le but
LC_ALL=C
est d'assurer un ordre de tri fiable entre les systèmes
- Cela ne fait pas la différence entre un répertoire «nommé \ nwithanewline» et deux répertoires «nommé» et «withanewline», mais la probabilité que cela se produise semble très improbable. On corrige généralement cela avec un
-print0
indicateur pour, find
mais comme il se passe d'autres choses ici, je ne peux voir que des solutions qui rendraient la commande plus compliquée que ça en vaut la peine.
PS: l'un de mes systèmes utilise une busybox limitée find
qui ne prend pas en charge -exec
ni les -print0
indicateurs, et ajoute également '/' pour désigner les répertoires, alors que findutils ne semble pas le faire, donc pour cette machine, je dois exécuter:
dir=<mydir>; (find "$dir" -type f | while read f; do md5sum "$f"; done; find "$dir" -type d | sed 's#/$##') | LC_ALL=C sort | md5sum
Heureusement, je n'ai pas de fichiers / répertoires avec des nouvelles lignes dans leurs noms, donc ce n'est pas un problème sur ce système.