HFS+ modifiziert Dateien eigenständig?

[equilux]

Hallo,

während ich Dateien per xcopy eindirektional von Windows auf einen Share auf Mac mit HFS+ als Dateisystem kopiere, stelle ich fest, daß zwischen dem 1. erfolgreichen xcopy-Run und dem 2. Run mehrere Dateien neu kopieren muss, weil sie sich auf dem Mac (Ziel) mehrere Dateien in kürzester Zeit geändert haben sollen.

Das will mir irgendwie nicht einleuchten. Das würde bedeuten, daß der Mac ohne meine Initiative die Dateien selbstständig verändert!?

Der xcopy Befehl ist so gesetzt, daß stets nur von Windows zum Mac kopiert wird und ich verwende folgende Parameter "robocopy [Windows-HDD] [Mac-Share] /MIR". D.h. es darf eine Datei nur kopiert werden, wenn sich entweder auf der Source die Datei ändert, oder die Zieldatei von der Source abweicht.

Daß der Befehl prinzipiell funktioniert und keine andauernden Neukopiervorgänge notwendig sind, weiß ich, denn wenn ich anstelle das Mac Shares einen Linux-Samba-Share reinhänge, klappt es einwandfrei mit dem mehrfachen kopieren. xcopy rennt schnell durch, sieht daß ale Dateien noch identisch sind und beendet sich ordnungsgemäß.

Hat jemand eine Idee, was MacOS und HFS+ da im Hintergrund machen und wie ich die kopierten Dateien auf dem Mac so ablegen kann, daß sie nicht mehr als "modified" bewertet werden?

Thx, Equi

P.S.: Passiert unter 10.9 und 10.10 gleichermaßen.

 

[cifera]

OS X unterstützt ja Dateiattribute, die es unter Windows nicht gibt, vielleicht wird da ja entsprechend was an den Dateien angehängt, was sie verändert erscheinen lässt.

 

[Hausbesetzer]

OS X unterstützt ja Dateiattribute, die es unter Windows nicht gibt, vielleicht wird da ja entsprechend was an den Dateien angehängt, was sie verändert erscheinen lässt.

Nein, die Datei muss immer gleich bleiben

 

[Pingu]

Wobei die Frage ist: Was hat sich geändert?

Also rsync nimmt das Modified-Datum und die Dateigröße. Man kann aber auch sagen, dass er eine CRC bilden soll.

Prinzipiell ändert der Rechner bei Benutzerdaten eigentlich nichts ständig.

 

[efx]

Pingu stellt eine gute Frage! Wenn sich nur die Größe ändert, was ich jetzt mal annehme, ist wohl die integrierte Dateikomprimierung von OS X schuld.

 

[Lor-Olli]

Selbst wenn nichts Komprimiert wird, weichen die Größenangaben von HFS+ und Windows (ntfs? Fat?) voneinander ab, einfach weil sie anders berechnet werden. (1 K sind wieviel Byte? ) Das wirkt sich ab einer gewissen Größe erst aus, weil bei kleinen Dateien die Abweichung gering ist. Mein Vorschlag, als erstes feststellen welche Dateien geändert werden (sich geändert haben) und welche Größe sie haben und ob die unveränderten Dateien eher die kleinen sind > Dann dürfte tatsächlich die unterschiedliche Größenberechnung schuld sein. Erste Abhilfe: den Größenvergleich auslassen und nur nach dem Datum gehen… (ist unbefriedigend, ich weiß) Alternativ den Größenvergleich in Bytes vornehmen, da muss man dann einen Rechenschritt zwischenbauen. (so hatte ich das mal gelöst, aber windowsdateien brauchte ich zum Glück nur eine sehr kurze Zeit abgleichen)

 

[spaceman88]

Pingu stellt eine gute Frage! Wenn sich nur die Größe ändert, was ich jetzt mal annehme, ist wohl die integrierte Dateikomprimierung von OS X schuld.

Seit wann werden alle Daten unter OS X komprimiert?

 

[dg2rbf]

hi..
hier wurde wohl die Speicherkomprimierung verwechselt..

Gruss Franz..

 

[mj]

Probier bei robocopy mal die Option /fft, eventuell passen die Zeitstempel der Quelle und des Ziels nicht zueinander weil die Genauigkeit der Differenzbildung zu fein ist.

 

[win2mac]

Ne stimmt schon. OS X hat seit Snow Leo eine Dateikompression bei HFS+.
Allerdings afaik nur bei Systemdateien.

Gruß

win2mac

 

[agrajag]

OS X unterstützt ja Dateiattribute, die es unter Windows nicht gibt, vielleicht wird da ja entsprechend was an den Dateien angehängt, was sie verändert erscheinen lässt.

Windows, respektive NTFS, hat sehr wohl Dateiattribute. Es kennt mit Streams sogar sowas wie Forks. Und ACLs kennt es, wenn ich mich nicht irre, sogar schon länger als HFS+.

 

[agrajag]

Hat sich vielleicht nur der Zugriffszeitstempel verändert? Das dürfte dann vielleicht der Spotlight-Indexer gewesen sein, sofern er dieses Attribut ändert. Du könntest ja mal ein Diff-Tool benutzen, um zu sehen, ob sich die reinen Nutzdaten der Datei verändert haben (was ich nicht wirklich annehme).

 

[cifera]

Windows, respektive NTFS, hat sehr wohl Dateiattribute. Es kennt mit Streams sogar sowas wie Forks. Und ACLs kennt es, wenn ich mich nicht irre, sogar schon länger als HFS+.

Ich hab auch nicht gesagt, dass es unter Windows keine gäbe.

 

[dedoteldot]

Hier steht was zu erweiterten Attributen bei HFS+.

Das erweiterte Attribute eine Datei verändern sieht man, wenn man z.B. einer Datei ein eigenes Icon zuweist: im Finder verändert sich die Dateigröße, im Terminal wird mit "ls" die alte Größe angezeigt. Die Frage ist nur, wo sollen diese Attribute herkommen?
Ob überhaupt welche da sind, kann man nach dem ersten xcopy mit einem

ls -l

im Zielverzeichnis prüfen. Zitat von der Seite:

...
Ein erstes Indiz für das Vorhandensein eines EA ist ein @-Zeichen bei der Ausgabe von ls -l:
$ ls -l
total 17488
-rw-r--r--@ 1 pronto staff 209428 14 Mai 14:19 Bilder
...

Dann kann man das ausschließen oder man weiß, wo man weiter sucht.

 

[agrajag]

Ich hab auch nicht gesagt, dass es unter Windows keine gäbe.

Was meintest du dann mit "OS X unterstützt ja Dateiattribute, die es unter Windows nicht gibt"?

Edit: Ah, du meinst bestimme Attribute. Ich hatte es ganz allgemein aufgefasst.

 

[equilux]

Probier bei robocopy mal die Option /fft, eventuell passen die Zeitstempel der Quelle und des Ziels nicht zueinander weil die Genauigkeit der Differenzbildung zu fein ist.

Danke für den Tipp. Ich probiere das morgen gerne mal aus und werde berichten.

Bedankt auch an die anderen erweiterten Hinweise bisher.