Post by Werner HoltfreterPost by Helmut WaitzmannPost by Werner HoltfreterLinuxPC USB-Stick Win7PC
ext4 fat32 NTFS
------------------------------
E <--> E
Unison zeigt ja sehr schön, was es synchronisieren möchte.
Ich öffnete eine vorhandene Excel-Datei auf dem USB-Stick mit dem
Win7PC, bearbeitete und speicherte sie unter einem neuen Namen
neu.xls. Eine weitere Excel-Datei alt.xls öffnete und schloss ich
auf gleichem Weg, speicherte sie aber nicht.
Unison hätte demnach neu.xls auf den LinuxPC kopieren müssen.
Hattest Du Unison auf dem LinuxPC vor dem Einhängen des
USB‐Ansteckspeichers beendet?
Ja.
Könnte es sein, dass Linux oder Unison auf dem LinuxPC mit
FAT32‐Dateisystemen anders umgeht als Windows und sie deshalb die
jeweils vom anderen Betriebssystem auf FAT32 hinterlassenen
Dateiattribute missverstehen?
Wie Synchronisations‐ oder Backup‐Programme unter Windows
heutzutage mit FAT32 umgehen, weiß ich nicht. Mir ist nur
bekannt, dass früher bei MSDOS das Archive‐Dateiattribut dazu
diente, festzuhalten, ob die Datei seit der letzten Archivierung
geändert wurde und daher neues Archivieren nötig hat. Ist das
auch bei aktuellen Windows noch so?
Im Gegensatz dazu kennt Linux (oder POSIX) kein Archive‐Attribut,
sondern verlangt von Archivierungs‐Programmen, dass sie sich zu
jedem Dateinamen die Dateinummer und den Zeitpunkt der letzten
Zustandsänderung der Datei merken. Archiviert werden muss eine
Datei genau dann nicht, wenn alle ihre Dateinamen, ihre
Dateinummer und ihr Zeitpunkt der letzten Zustandsänderung mit
denen, die sich das Archivierungs‐Programm bei der letzten
Archivierung gemerkt hat, übereinstimmen.
Post by Werner HoltfreterPost by Helmut WaitzmannPost by Werner HoltfreterAber Unison bemerkte neu.xls überhaupt nicht. Stattdessen
behauptete Unison alt.xls auf dem USB-Stick sei geändert worden,
zeigt aber in der Fußzeile seines Fensters die Datei auf LinuxPC
und USB-Stick mit identischer Dateigröße und identischem
Änderungsdatum an.
Unison auf dem LinuxPC schlägt also vor, „alt.xls“ vom
USB‐Ansteckspeicher auf den LinuxPC zu kopieren?
Ja.
Bist Du sicher, dass Windows die Datei „alt.xls“ nicht geändert
hat? Dass auf den Zeitstempel der letzten Inhaltsänderung weder
in der Unix‐ noch in der Windows‐Welt Verlass ist, ist ja bekannt.
Post by Werner HoltfreterPost by Helmut WaitzmannPost by Werner HoltfreterIch schließe Unison und kopiere neu.xls auf den LinuxPC.
Nach erneutem Start von Unison möchte Unison die unveränderte
Datei immer noch auf den USB-Stick kopieren,
„Immer noch?“ Oben schreibst Du davon, dass Unison auf dem
LinuxPC eine Datei vom USB‐Ansteckspeicher auf den LinuxPC
kopieren möchte. Dass es auch in der umgekehrten Richtung, auf
den USB‐Ansteckspeicher, kopieren will, hast Du nichts
geschrieben.
Verstehe ich hier etwas falsch?
Kann sein. „alt.xls“ war identisch auf dem USB-stick und auf dem
LinuxPC vorhanden. Möglicherweise durch den vorausgegangenen
Lesezugriff auf die auf dem USB-Stick befindliche Datei wurde diese
fälschlich als verändert wahrgenommen. Beim zweiten Start von
Unison war das immer noch so. Und jetzt, nach zwischenzeitlichem
Abstecken des USB-Sticks und Reboot ist es immer noch so.
Uns seitdem will Unison die Fassung der Datei „alt.xls“ auf dem
LinuxPC auf den USB‐Ansteckspeicher kopieren (und dabei die
anscheinend neue Fassung auf dem Ansteckspeicher überschreiben)?
Das ist in der Tat sehr seltsam.
Post by Werner HoltfreterPost by Helmut WaitzmannPost by Werner Holtfreterjetzt aber zusätzlich und überflüssiger Weise die eben manuell
kopierte Datei neu.xls vom LinuxPC zum USB-Stick kopieren.
Unison hat die Datei auf dem LinuxPC möglicherweise erst nach dem
erneuten Start bemerkt und hält sie deswegen jetzt für neu.
Naja, eigentlich ist sie ja dort auch neu.
Die auf dem USB-Stick befindliche Datei neu.xls wird nicht gefunden.
Statt dessen wird die manuell erzeugte Kopie neu.xls auf den
LinuxPC richtiger Weise als neu erkannt, aber nun Versucht Unison,
sie auf den USB-Stick zu kopieren, obwohl sie ja von dort herstammt
und noch dort ist.
Dass sie von dort stammt, kann Unison doch nicht wissen. Dass der
Inhalt der gleiche ist, verifiziert es ja auch nicht (siehe die
Zitate weiter unten).
[…]
Post by Werner HoltfreterPost by Helmut WaitzmannUm den Verdacht, dass FAT32‐Dateisysteme den Zeitpunkt der letzten
Änderung der Metadaten einer Datei nicht speichern, zu erhärten
oder zu widerlegen, bitte ich Dich, auf dem FAT32‐Dateisystem
Lege eine Datei an, etwa „neu.xls“, wie oben. Lass Dir den
Zeitpunkt der letzten Metadatenänderung mit dem Kommando
ls -ldogic -- neu.xls
und den Zeitpunkt der letzten Dateiinhaltsänderung mit dem
Kommando
ls -ldogi -- neu.xls
anzeigen. Warte mindestens 2 Sekunden (genauer sind die
Zeitstempel im FAT32‐Dateisystem möglicherweise nicht).
Ändere die Datei „neu.xls“.
Hänge den USB‐Ansteckspeicher aus und zieh ihn ab. Hänge ihn
erneut ein.
Führe jetzt die zwei genannten „ls“‐Kommandos erneut aus.
Poste bitte die Ausgaben aller 4 „ls“‐Kommandos.
6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
Auf einem Dateisystem, das sich Dateinummern merkt, stände in der
Ausgabe der beiden folgenden Kommandos in der ersten Spalte noch
immer die Zahl 6689 wie oben.
Post by Werner Holtfreter6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
Beide Zeitinfos haben sich demnach geändert.
Das beweist immerhin, dass Linux den Zeitpunkt der Dateierstellung
nicht als Zeitpunkt der letzten Dateizustandsänderung
missversteht.
Post by Werner HoltfreterDer Gedanke mit den Metainformationen lag nahe, solange die Datei
nur geändert wird und das nicht erkannt wird. In meinem Fall wurde
aber eine Datei auf dem USB-Stick mit einem Namen angelegt, den es
dort vorher noch nicht gab. Das sollte erkennbar sein.
Sollte man eigentlich meinen.
Da kann ich mir nur Unison‐Falschanwendung oder einen riesigen
Fehler bei Unison vorstellen. (Du hast bisher nichts dazu
geschrieben, wie Du Unison konfiguriert hast, und nichts dazu, wie
Du es aufgerufen hast.)
Aus der Unison‐Dokumentation:
<https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#updates>
Das hört sich gut an:
Unison keeps a record of the contents of each path after each
successful synchronization of that path (i.e., it remembers the
contents at the last moment when they were the same in the two
replicas).
We say that a path is updated (in some replica) if its current
contents are different from its contents the last time it was
successfully synchronized. Note that whether a path is updated
has nothing to do with its last modification time—Unison
considers only the contents when determining whether an update
has occurred. This means that touching a file without changing
its contents will not be recognized as an update. A file can
even be changed several times and then changed back to its
original contents; as long as Unison is only run at the end of
this process, no update will be recognized.
Das schreckt mich auf:
What Unison actually calculates is a close approximation to this
definition; see the Caveats and Shortcomings section.
Im Abschnitt „Caveats and Shortcomings“
(<https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#caveats>)
steht dann:
Here are some things to be careful of when using Unison.
* In the interests of speed, the update detection algorithm
may (depending on which OS architecture that you run
Unison on) actually use an approximation to the definition
given in the What is an Update? section.
Beim folgenden
In particular, the Unix implementation does not compare
the actual contents of files to their previous contents,
but simply looks at each file's inode number and modtime;
if neither of these have changed, then it concludes that
the file has not been changed.
Under normal circumstances, this approximation is safe, in
the sense that it may sometimes detect “false updates” but
will never miss a real one. However, it is possible to
fool it, for example by using retouch to change a file's
modtime back to a time in the past.
ziehe ich die Reißleine: Ein Programm, das unter Linux den
Zeitstempel der Inhaltsänderung einer Datei als Maßstab für
Änderungen heranzieht, ist für mich inakzeptabel: Dieser
Zeitstempel kann unter Linux auf einen beliebigen Wert in der
Vergangenheit, Gegenwart und Zukunft gesetzt werden. Daran zu
entscheiden, ob eine Datei archiviert oder synchronisiert werden
muss, ist nicht verlässlich möglich.
Dazu kommt, dass FAT32 keine inode numbers hat. Die werden aber
laut dem angeführten Zitat von Unison bei Unix zwingend gebraucht.
Post by Werner HoltfreterWenn wir die Ursache nicht finden, kann ich auf dem USB-Stick auch
ein anderes Dateisystem installieren - welches empfiehlst du?
Keine Ahnung. Dazu müsste man erst mal Bescheid wissen, ob es
überhaupt eines gibt, das sich Zeitstempel der letzten
Zustandsänderung merkt und von Linux und Windows in kompatibler
Weise verwendet wird. Vielleicht NTFS oder ext2? (Gerüchtehalber
soll es ext2‐Treiber für Windows und NTFS‐Treiber für Linux geben.
Wie vollständig die sind, weiß ich nicht.)
Aber vielleicht gibt es die Möglichkeit, ein Archivierungsprogramm
zu verwenden, das die archivierten Dateien nicht in ein
Dateisystem sondern in ein Archiv schreibt, und zwar auf eine
Weise, die es erlaubt, ein unter Linux geschriebenes Archiv unter
Windows auszupacken und umgekehrt. Dann könnte man zumindest den
Transport von neuen Dateien von Linux zu Windows und umgekehrt
hinbekommen.
Post by Werner HoltfreterAber schöner wäre es, zunächst die Ursache zu finden.
Ich vermute Unzulänglichkeiten zwischen Linux und FAT32 in
Verbindung mit den oben zitierten Beschränkungen bei Unison.