Fehler beim Ändern von Änderungsdaten durch rsync, selbst mit der Option -a

Ich habe rsync getestet und beim Kopieren von Dateien und Ordnern von einer Partition auf eine andere einen seltsamen Fehler gefunden:

Wenn ich das mache:

rsync -avE --delete '/Volumes/disk1/origin/' '/Volumes/disk2/destination/'

Es kopiert/synchronisiert korrekt.

Wenn ich das nächste Mal rsync für die gleiche Synchronisierung verwende, werden einige Änderungsdaten in Dateien (nicht Ordnern!) Falsch (werden auf das aktuelle Datum und die aktuelle Uhrzeit geändert), obwohl ich das in dem Befehl verwendet habe, der es beibehalten -asollte rsync.

Das Seltsamste ist, dass, wenn ich es wiederhole, die falschen Daten jetzt korrekt sind, was bedeutet, dass rsync die Änderungsdaten jedes zweite Mal ändert, wenn es ausgeführt wird, und wenn es die Daten ändert, sind es immer die gleichen Dateien. Ich sehe kein anderes Muster als nur Dateien und dieselben Dateien zu beeinflussen.

Was mache ich falsch und kann das behoben werden?

Dies ist mit OS X 10.9.5 unter Verwendung des Terminals rsync 2.6.9

Was sind die Dateisysteme auf diesen beiden Volumes? FAT hat ein notorisches Designproblem, bei dem Änderungszeiten nur mit einer Auflösung von 2 Sekunden dargestellt werden können. rsync kommt damit nicht immer gut zurecht.
@ChrisHarrington sind beide mit Mac OS Extended (Journaled) und mit einer Standard-GUID-Partitionstabelle.
Siehe Kommentare hier rsync 2.6.9 hat einen bekannten Fehler bei Änderungszeiten - besorgen Sie sich eine neuere Version
@Mark Ich habe vermutet, dass rsync möglicherweise aktualisiert werden muss, was ich testweise getan habe (aktualisiert auf Version 3.1.0), aber das Erstellungsdatum (im Fall dieser neuen Version) wird nicht beibehalten ... Also Teil der Problem ist gelöst, jetzt habe ich ein neues. Vielleicht muss ich verschiedene Optionen verwenden und nicht nur die -avE?
Das Erstellungsdatum von @jackJoe ändert sich immer, wenn eine Datei einen neuen Inode erhält (na ja, eine Katalogknoten-ID in hfs). Ich gehe davon aus, dass Sie einen 64-Bit-Kernel ausführen. In diesem Fall sollte die Geburtszeit erhalten bleiben. Hast du rsync selbst kompiliert?
@fd0 ja, 64-Bit-Kernel, und ich habe das neue rsync kompiliert. Beim Kopieren mit dem Finder (Drag and Drop) bleibt alles wie gewünscht erhalten. Dieses neue Problem besteht auch darin, dass das Erstellungsdatum gleich dem Änderungsdatum wird (in diesem neuen Fall ist das Änderungsdatum korrekt).
@jackJoe Ich kann einige Ihrer Beobachtungen reproduzieren. Zur Verdeutlichung bestehen 64-Bit-Zeitstempel aus access-modification-creation-birthtime. In Finder-Begriffen ist die Geburtszeit die Erstellungszeit. Ein anfänglicher Lauf von rsync -av SOURCE DESTINATIONbewahrt die Zugriffsänderung und die Erstellungszeit der Geburtszeit wird zu der Zeit, zu der rsync den Inode erstellt hat. Wenn Dateien im SOURCE-Ordner geändert werden, rsyncwird beim nächsten Durchlauf die Geburtszeit der DESTINATION-Datei auf die Erstellungszeit der SOURCE-Datei geändert. - OS X 10.6, 64bit mit rsync 3.1.1. Ich denke, dies ist ein Problem mit OS X, nicht mit rsync, werde es weiter untersuchen.

Antworten (1)

Lassen Sie mich meinen Kommentar korrigieren: Ein 64-Bit-Zeitstempel besteht aus access-modification-change-birthtime.

Ab man 2 statden folgenden Systemaufrufen ändern sich die jeweiligen Zeiten.

Die zeitbezogenen Felder von struct stat lauten wie folgt:

 st_atime         Time when file data last accessed.  Changed by the mknod(2), utimes(2) and read(2) system calls.

 st_mtime         Time when file data last modified.  Changed by the mknod(2), utimes(2) and write(2) system calls.

 st_ctime         Time when file status was last changed (inode data modification).  Changed by the chmod(2), chown(2), link(2), mknod(2), rename(2),
                  unlink(2), utimes(2) and write(2) system calls.

 st_birthtime     Time of file creation. Only set once when the file is created. This field is only available in the 64 bit inode variants. On filesys-
                  tems where birthtime is not available, this field holds the ctime instead.

Tools wie cp, ditto, und paxkönnen OS X-Metadaten beibehalten, wenn sie zum Kopieren von Dateien aufgerufen werden. Diese Tools behalten die Geburtszeit nicht bei, wenn die Änderungszeit neuer ist als die Geburtszeit der Originaldatei. Die Entstehungszeit der neuen Datei wird auf die Änderungszeit der Originaldatei gesetzt.

Wenn Sie rsync mit den Patches fileflags, crtimes, hfs-compression kompilieren, kann rsync OS X-Metadaten verarbeiten und die Geburtszeit der Originaldatei in der neuen Datei beibehalten.

Sie würden also rsync so aufrufen.

rsync -avXN --delete SOURCE DESTINATION

Ich schlage vor, dass Sie das rsync-Handbuch ausführlich lesen und die von mir vorgeschlagenen Optionen verstehen, bevor Sie versuchen, sie anzuwenden.

Nach Ihrem Vorschlag und diesem Tutorial zum Upgrade von rsync selfsuperinit.com/2014/01/04/… Ich habe das verwendet rsync -avXN --delete SOURCE DESTINATIONund es funktioniert großartig, alle Änderungsdaten, Erstellungsdaten usw. werden beibehalten, also Problem gelöst, danke!
-N ist keine Option. Meinten Sie -n für Probelauf? Allerdings funktioniert das bei mir immer noch nicht. macOS Sierra 10.12 mit rsync 3.1.2 (manuell aktualisiert). Das Erstellungsdatum auf dem Ziel kopiert das Änderungsdatum auf der Quelle.
@lukejanicke- Hast du die Patches angewendet, die ich erwähnt habe? Wenn ja, -Nsollte die Option verfügbar sein. Von rsync -h: -N, --crtimes preserve create times (newness).
@jackJoe Der von Ihnen geteilte Link ist defekt. Ich nahm an, dass es nur ein Tutorial zum Upgrade war. Ich habe manuell auf rsync 3.1.2 aktualisiert und es gibt immer noch kein -N in den Optionen. Enthält dieses Tutorial mehr als Upgrade-Anweisungen?
Ich habe dies romej.com/2016/04/rsync-backups-on-os-x gefunden , das erklärt, wie die Patches eingefügt werden, von denen ich nicht wusste, dass sie separat sind.
Fehler beim Ändern von Änderungsdaten durch rsync, selbst mit der Option -a
AntwortenHierDatenschutz-Bestimmungen1y, 0v