5 votes

Comment puis-je sauvegarder un disque externe tout en préservant les attributs, la date de création du dossier et en affichant la progression ?

Objectif final

  • Créez une copie de tous les fichiers d'un disque dur externe vers un autre disque dur externe, tous deux formatés en HFS+.
  • Préserver le dossier date de création.
  • Conserver l'étiquette de couleur du chercheur.
  • Pendant la copie, je veux voir une sorte d'indicateur de progression.

Utilisation de cp

Si je copie en utilisant

cp -a /origin/folder/ /destination/folder

cela ne fait que préserver fichier les dates de création, et non dossier les dates de création.

Utilisation de rsync 3.1.3

Si je copie en utilisant rsync 3.1.3 (installé via Homebrew)

rsync --recursive --info=progress2 -hhh --xattrs --times --crtimes /origin/folder /destination/folder 

Cela préserve les dates de création des dossiers et les étiquettes de couleur, mais le résultat est truffé des erreurs ci-dessous (je ne peux pas les masquer avec la commande --quiet ), je ne peux donc pas suivre la progression

rsync: get_xattr_names: llistxattr("/origin/folder/filename",1024) failed: Operation not permitted (1)

3voto

Saaru Lindestøkke Points 5124

Juste après avoir posté cette question, j'ai trouvé une solution.

J'ai remarqué que le rsync: get_xattr_names avaient toutes une chose en commun : les fichiers qui provoquaient l'erreur étaient toujours ._ des fichiers.

J'ai lu que ._ Les fichiers sont utilisé pour stocker des informations qui iraient dans un attribut étendu HFS+. . Comme je copie entre des disques HFS+, je me suis dit que je n'avais pas besoin de ces fichiers.

J'ai donc ajouté un --exclude à ma commande rsync qui exclut tous les noms de fichiers qui commencent par ._

rsync --exclude="._*" --recursive --info=progress2 -hhh --xattrs --times --crtimes /Volumes/origin/ /Volumes/destination

La commande :

  • Filtres ._ au préalable ( --exclude="._*" ), empêchant get_xattr_names erreurs.
  • Préserve les dates de création des dossiers via l'option --times --crtimes argument.
  • Préserve les étiquettes de couleur du Finder via le --xattrs argument.
  • Montre les progrès réalisés dans un format lisible par l'homme via le --info=progress2 -hhh argument.
  • (Bonus supplémentaire : préserve également les icônes de dossier personnalisées, via la fonction --xattrs argument)

0 votes

A noter également -a, --archive - archive mode; same as -rlptgoD (no -H) . Lorsque je l'utilise (MacOS et Linux), je spécifie toujours -a mais même s'il comprend -t Je pourrais jurer que je l'ai déjà vu à plusieurs reprises et je le spécifie donc toujours explicitement.

0 votes

Merci, je connaissais l'option archive, mais j'ai pensé que je comprendrais mieux la commande en utilisant (et en lisant) chaque argument séparément. Lorsque vous dites seen it not preserve times Vous voulez dire le temps de création ? Si c'est le cas, c'est normal, car seul le (mac seulement ?) --crtimes L'argument s'en charge.

0 votes

Non. Je voulais parler des délais de modification. Sous Linux, peu de systèmes de fichiers ont même un temps de création. Et je comprends tout à fait que l'on veuille connaître toutes les options. C'est une bonne habitude à prendre, surtout si vous n'avez pas l'habitude de la commande ! En fait, c'est comme ça que j'ai commencé, mais c'était il y a très longtemps maintenant. (Je le fais aussi pour MacOS) Oh et +1 pour la question et la réponse. Je sais qu'au moins sur certains sites SE, il est tout à fait acceptable d'accepter sa propre réponse. Peut-être que ce n'est pas le cas pour Apple SE, mais je pensais juste le mentionner.

1voto

newyork10023 Points 73

Dans votre réponse, vous écrivez : "J'ai lu que les fichiers ._ sont utilisés pour stocker des informations qui entreraient dans un attribut étendu HFS+. Comme je copie entre des disques HFS+, je me suis dit que je n'avais pas besoin de ces fichiers."

Je ne ferais pas cette supposition sans effectuer d'autres tests. Il n'est pas nécessaire que les informations sur les fourchettes de ressources saisies dans ces fichiers dot bar existants aient été (ré)incorporées dans le fichier associé.

Il existe un article Wikipedia sur les "formats AppleSingle et AppleDouble" :

https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats

Les fichiers "dot bar" peuvent être créés dans un certain nombre de cas, par exemple, voir :

Pourquoi des fichiers ._ avec des points de soulignement sont-ils créés, et comment puis-je les éviter ?

La question de savoir s'il faut réincorporer les fichiers dot bar a été discutée ici :

Comment réconcilier les fichiers dot-underscore après une sauvegarde manuelle ?

La commande OS X/MacOS dot_clean dispose d'un certain nombre d'options quant à la manière de les traiter :

--keep=mostrecent

L'option par défaut. Si un attribut est associé à une fourchette de données, utilisez-la. Sinon, utiliser les informations stockées dans le fichier AppleDouble. Notez que les données de la fourche native sont préférées même si les données du fichier AppleDouble sont plus récentes.

--keep=dotbar

Utilisez toujours les informations stockées dans le fichier AppleDouble, en remplaçant tout attribut étendu associé au fichier natif.

--keep=native

Utilisez toujours les informations associées à la fourche de données, en ignorant les éventuels fichiers AppleDouble.

Vous pouvez consulter man dot_clean pour de plus amples informations et options.

Vous pouvez lever une partie de l'incertitude en déterminant si les fichiers auxquels est associée une barre de points contiennent des informations sur les fourchettes de ressources. sans référence aux fichiers dot bar. Cela pourrait être un peu compliqué à tester, car la copie des fichiers pourrait réincorporer les fichiers dot bar pendant la copie.

Vous pouvez ne pas vous en soucier, ou ne pas prendre le temps de le déterminer, et simplement exécuter dot_clean avec son option par défaut.

Ou bien, vous pouvez ignorer le problème pour l'instant et ne pas exclure les fichiers dot bar pendant vos sauvegardes rsync.

Il convient de souligner qu'une grande partie de cette discussion porte sur la manière de traiter la source/origine de la sauvegarde. On peut supposer que le but d'une sauvegarde est de dupliquer aussi exactement que possible la source. En tant que tel, je n'exclurais pas les fichiers dot bar comme faisant partie de votre sauvegarde. Je chercherais plutôt à savoir pourquoi les fichiers dot bar existent dans votre source. Ensuite, il s'agit de savoir si, et plus tard comment, il faut les "réparer".

0 votes

Merci pour cet article détaillé. Dans votre dernier paragraphe, vous dites I would look to the cause of these issues in your source . De quels problèmes s'agit-il ? Qu'il n'y a pas d'attribut que rsync peut obtenir de l'élément ._ fichiers ?

0 votes

L'existence des fichiers ._ eux-mêmes. Le système de fichiers HFS+ peut "intégrer" les fourches de ressources de manière native. Les fichiers dot bar sont généralement utilisés comme mécanisme de transfert de la fourche de ressources vers un système de fichiers ne disposant pas d'un support natif. Pourquoi la fourche de ressource n'a-t-elle pas été intégrée lors de la création des fichiers associés ? En effet, les fichiers associés ont-ils une fourche de ressource ? Et, si c'est le cas, la fourche de ressource correspond-elle aux informations contenues dans les fichiers dot bar associés ? (La réponse a été modifiée pour plus de clarté.)

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X