Verhalten von rsync bei TIF-Dateien

[isarcanoe]

Schon seit Jahren mache ich mein Delta-Backup per Script, dessen Kern ein rsync-Kommando ist.
(rsync -avE --delete --exclude-from=$… /Volumes/Daten/$…./ /Volumes/$ziel/$…./)

Das hat immer einwandfrei funktioniert bis auf eine Sache:

Die TIFF-Dateien werden meist neu kopiert, obwohl sie nicht geändert wurden.
(Bei kurz aufeinanderfolgenden Durchläufen ohne Änderung der Daten zeigt sich manchmal ein seltsames Verhalten: mal werden alle TIFF-Daten korrekterweise nur verglichen, mal unkorrekterweise komplett neu kopiert.)
Der Fehler ist kaum zu reproduzieren, es ist immer wieder anders.
Bei JPEG passiert das nicht.

Hat jemand eine Idee, warum das passiert oder gar wie man das abstellt ?

 

[wegus]

Sind Zeitstempel und Dateigröße wirklich identisch. Bist Du Dir sicher, dass der rsync hier wirklich unnötig erfolgt? TIFF ist ein Datencontainer der Vorschaubild, EXIF-Daten und Das Bild (komprimiert) enthält. Es kann hier reichen das irgendwer (z.B. eine Bildbearbeitung) die Vorschaubilder aktualisiert - auch wenn diese sich optisch nicht verändern. Daher würde ich vorher mal genau auf die Zeitstempel und Größe in Bytes achten!

 

[isarcanoe]

@wegus: dann müßte ja Photoshop oder der Finder oder ... ständig Tausende von TIFF-Dateien anfassen und irgendwas ändern.
Wie schon geschrieben: die TIF-Dateien werden auch komplett neu kopiert, obwohl kurz zuvor ein Backup gemacht wurde.

 

[wegus]

müßte, könnte, täte...

genau das ist aber durchaus möglich! Darum würde ich es mal prüfen. rsync ist so ein etabliertes und verbreitetes tool, dass ich da eher nicht von einer Fehlfunktion ausgehe. Ich vermute das irgendwer/irgendwas entweder den content oder die access times der Dateien tatsächlich verändert und rsync hier korrekterweise synchronisiert. Sprich: ich vermute der rsync ist nur das Symptom.

 

[isarcanoe]

Danke wegus,
da werde ich mal heute abend in diese Richtung suchen

 

[pmau]

Spotlight Metadaten vielleicht. Die sichert rsync mit und sie sind quasi Teil der Datei.
Ist aber nur geraten.

 

[asterixxER]

Ich hatte probleme mit dem rsync (Abbrueche) von osx und habe einen neueren ueber macports installiert. Danach waren die Abbrueche weg.

 

[wegus]

Du kannst auch noch probieren auf Vergleiche Einfluß zu nehmen. Z.B. mit:

--size-only skip files that match in size
-c, --checksum skip based on checksum, not mod-time & size

 

[isarcanoe]

Danke für Eure Tipps.
Ich werde zunächst mal eine Zeit lang einige ausgewählte TIFF überwachen, indem ich regelmäßig ein Script laufen lasse, das mir die kritischen Werte in jeweils eine Datei schreibt:
Datei Aenderungsdatum Dateigroesse Checksumme
Test3.tif So 11 Jun 2017 11:43:27 38808620 42a8b43a917dccc936854bc7806a23
Test3.tif So 11 Jun 2017 11:43:27 38808620 42a8b43a917dccc936854bc7806a23
Test3.tif So 11 Jun 2017 11:43:27 38808620 42a8b43a917dccc936854bc7806a23
Wenn sich hier nichts ändert, erweitere ich die Kontrolle auch auf die Daten auf dem Backupvolume.
Dann sehe ich weiter und berichte darüber.

 

[Olivetti]

es kommt evtl. auf die rsync-version an, die du verwendest (stichwort -E ≈ xattr oder execute).
das alte osx-rsync hat bei -E eine andere bedeutung, als die generellen, neuen.
was zeigt denn deine version unter -E bei rsync -h?

 

[isarcanoe]

man rsync zeigt folgendes an: (Sierra)
-E, --extended-attributes copy extended attributes, resource forks
(behält die Ausführbarkeit von Dateien bei !?)

 

[Olivetti]

dann solltest du in deinem script aus #9 auch die xattribute mitüberwachen.

 

[isarcanoe]

Jetzt wird es für mich schwierig. Meinst Du das Vorhandensein des "@" in "-rwxr-xr-x@ ?
Für einen tiefergehenden Tip wäre ich dankbar.

(nebenbei: jetzt habe ich beim rsync auch -c dazugenommen)

 

[Olivetti]

genau.
um so ziemlich alle metadaten zu betüddeln -> ls -leO@

>rsync -c
ja, so kannst du es natürlich auch lösen, dauert aber sicher länger und mich würde jetzt interessieren, wer/was bei dir die files anfasst.

 

[isarcanoe]

... da scheint was verlorengegangen zu sein - also nochmal:
Das mit den Metadaten ist mir eine Nummer zu hoch
Die Abfrage bringt z.B.
com.apple.FinderInfo 32
com.apple.ResourceFork 44790
com.apple.metadata:_kMDItemUserTags 42
aber mit meinen besch... UNIX-Grundkenntnissen kann ich nichts anfangen damit.

 

[Olivetti]

es ist relativ einfach. brauchst du die xattributes wirklich oder nicht?

 

[isarcanoe]

Es ging ja darum, ob das OS „über die xattributes Änderungen verursacht“ (#12)
Aber wie ich die überwachen kann, weiß ich nicht.
tja Olivetti, meine wenigen UNIX-Fähigkeiten stoßen da an die Grenze und wenn es jetzt zu kompliziert wird, muß ich wohl mein Vorhaben aufgeben.

Bei meinen Testdateien sind Änderungdatum, Dateigröße und Prüfsumme bisher gleichgeblieben, aber die Zeit ist noch zu kurz.

Danke für Deine bisherige Mühe und Geduld.

 

[Olivetti]

deswegen ja die frage. anschauen kann man das mit z.b. xattr. wenn's die attribute aber binary sind, dann musst du evtl. noch wandeln oder z.b. hex in eine datei wegschreiben und vergleichen.

"xattr file" zeigt welche xattributes vorhanden sind -> z.b. com.apple.FinderInfo
"xattr -p[x] com.apple.FinderInfo file" zeigt dann den inhalt des xattributes -> z.b. käme hier ein hex string.

vermutlich ist es einfacher, wenn du auf -E verzichtest.

 

[isarcanoe]

"vermutlich ist es einfacher, wenn du auf -E verzichtest"
Danke, das mach ich mal als Erstes.
Gleichzeitig verfolge ich eine Zeitlang weiter, ob "Änderungdatum, Dateigröße und Prüfsumme" unverändert bleiben.
Wenn es dann was zu berichten gibt, werde ich mich wieder melden.
Nochmals Danke

 

[isarcanoe]

Nun habe ich das eine Weile verfolgt. Änderungdatum, Dateigröße und Prüfsumme blieben bei den Testdaten unverändert,
es hängt nur am Schalter rsync -E, den ich jetzt weglasse
(hätt ich ja selber ausprobieren können 8-(( - Olivetti, bitte um Nachsicht)

Es funktioniert wunschgemäß:

a) mit rsync -av
wenn im Quell-Volume nichts verändert wurde, Durchlauf für 62 000 Dateien / 840 GByte in 13 Sekunden
rsync-Meldung am Terminal lediglich "building file list ... done" (und sonst keine Dateien/Ordner gelistet)

b) mit rsync -avc (mit Berechnung der Prüfsumme)
wenn im Quell-Volume nichts geändert wurde, Durchlauf für 62 000 Dateien / 840 GByte in 3h 20' = 12 000 Sekunden,
zuerst Quellvolume 6000 s, dann Zielvolume 6000 s
nach Zeitmessung 840 000 MByte/s / 6 000 s = 140 MByte/s; nach Aktivitätsanzeige ~110 MByte/s (beide Volumes haben USB3),

c) wenn Dateien/Ordner verändert wurden, werden diese am Terminal gelistet und übertragen (mit entsprechen längerer Zeit)