expertenaustausch > comp.* > comp.software.misc

Werner Holtfreter (20.07.2018, 10:26)
Hallo,

folgende Geräte/Verzeichnisse synchronisiere ich mit Unison:

LinuxPC USB-Stick Win7PC
ext4 fat32 NTFS
------------------------------
E <--> E

Unison zeigt ja sehr schön, was es synchronisieren möchte.
Dabei sind mir mehrfach Lücken in folgender Art aufgefallen:

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.

Aber 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.

Ich 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, jetzt aber zusätzlich und
überflüssiger Weise die eben manuell kopierte Datei neu.xls vom
LinuxPC zum USB-Stick kopieren.

Im betreffenden Synchronisationsprofil ist gesetzt:

Name fat
Type boolean
Value true
Description: When this is set to true, Unison will use appropriate
options to synchronize efficiently and without error a replica
located on a FAT filesystem on a non-Windows machine: do not
synchronize permissions (perms = 0); never use chmod ({ t dontchmod
= true}); treat filenames as case insensitive (ignorecase = true);
do not attempt to synchronize symbolic links (links = false);
ignore inode number changes when detecting updates
(ignoreinodenumbers = true). Any of these change can be overridden
by explicitly setting the corresponding preference in the profile.

Was läuft da schief?
Helmut Waitzmann (20.07.2018, 23:19)
Werner Holtfreter <holtfreter>:

[..]
>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?
<https://de.wikipedia.org/wiki/Unison_%28Software%29#Funktionsweise>
legt nahe, dass das nötig ist:

Unison prüft nach dem Start den Dateibestand pro Verzeichnis
bzw. Computer und vergleicht die Zeitstempel der Dateien. Stellt
es Veränderungen fest, werden die Änderungen der entsprechenden
Dateien genauer analysiert. Danach erstellt Unison eine
Replikationsliste mit Vorschlägen für deren Synchronisation und
markiert nicht automatisch auflösbare Konflikte.

>Aber 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?

>Ich 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?

>jetzt 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.

>Im betreffenden Synchronisationsprofil ist gesetzt:
>Name fat
>Type boolean
>Value true
>Description: When this is set to true, Unison will use appropriate
>options to synchronize efficiently and without error a replica
>located on a FAT filesystem on a non-Windows machine: do not
>synchronize permissions (perms = 0); never use chmod ({ t dontchmod
>= true}); treat filenames as case insensitive (ignorecase = true);
>do not attempt to synchronize symbolic links (links = false);


Das folgende

>ignore inode number changes when detecting updates
>(ignoreinodenumbers = true).


kann auch eine Quelle nicht erkannter Dateiänderungen sein.

FAT32?Dateisysteme speichern keine Dateinummern (inode numbers).
Weil die aber in POSIX?kompatiblen Umgebungen wie beispielsweise
Linux von Synchronisationsprogrammen gebraucht werden, um neue
Dateien zu erkennen, muss der FAT32?Treiber von Linux bei jedem
Einhängen des FAT32?Dateisystems welche aus dem Hut zaubern. Wenn
er bei jedem Neueinhängen des FAT32?Dateisystems neue Nummern aus
dem Hut zaubert ? was er muss, weil die vom letzten Mal nicht im
Dateisystem vermerkt werden ?, kann Unison alte Dateien nicht
anhand des Zeitpunkts der letzten Änderung der Metadaten in
Verbindung mit der Dateinummer wiedererkennen und hält
zwangsläufig alle(!) Dateien für neu.

Deswegen bietet es an, Dateinummern zu ignorieren. Die Kehrseite
dabei ist, dass es ohne das Wiedererkennen von Dateien anhand der
Dateinummer nicht sicher entscheiden kann, ob eine Datei neu ist
oder nicht. Weder der im FAT32?Dateisystem vermerkte Zeitpunkt
der letzten Änderung des Dateiinhalts noch der der Dateierzeugung
reicht dazu aus.

>Was läuft da schief?


Ich habe den Verdacht, da schlägt das Problem, vor dem in
<https://de.wikipedia.org/wiki/Unison_%28Software%29#Einschr%C3%A4nkungen>
gewarnt wird, zu:

Findet die Replikation zwischen unterschiedlichen Dateisystemen
statt, können Probleme in den folgenden Bereichen auftreten:

* Dateiattribute, wenn sie nicht gleichartig von beiden
Dateisystemen unterstützt werden (Beispiel: FAT32-
ggü. POSIX-Attribute)

Dieses Problem ist nicht nur eines von Unison, sondern generell
eines von Synchronisations? und Backup?Programmen, die sichauf
das von Posix bereitgestellte Dateiattribut ?Zeitpunkt der letzten
Änderung der Metadaten der Datei? in Verbindung mit der
Dateinummer stützen, wenn man sie auf ein Dateisystem
(beispielsweise FAT32) loslässt, das dieses Dateiattribut und die
Dateinummer nicht anbietet:

<https://de.wikipedia.org/wiki/Dateiattribut#Beispiele_f%C3%BCr_Metadaten>
zählt einige Dateiattribute auf:

Beispiele für Metadaten

[?]

* Datum und ggf. Uhrzeit

[?]

o des letzten Schreibzugriffs auf die Datei (unter
Posix mtime, unter Windows Last Write)

o der Änderung des Dateiinhalts, wird mitunter
gleichgesetzt mit dem letzten Schreibzugriff auf die
Datei, da vor einem Schreibzugriff üblicherweise
nicht überprüft wird, ob sich durch ihn der Inhalt
tatsächlich ändert

o der Änderung der Metadaten der Datei (unter Posix
ctime)

o des letzten Zugriffs auf die Datei (unter Posix
atime, unter Windows Last Access), unter Windows
wird mit dieser Angabe auch die Änderung von
Metadaten wie Dateiattributen erfasst

[?]

Laut
<https://de.wikipedia.org/wiki/FAT32#Stammverzeichnis_und_Unterverzeichnisse>
wird der Zeitpunkt der letzten Änderung der Metadaten der Datei im
FAT32?Dateisystem nicht gespeichert. (Es gibt zwar den Zeitpunkt
der Erstellung der Datei. Der ändert sich aber im Laufe des
Lebens einer Datei nicht mehr und ist daher ungeeignet als
Ersatz.)

Auch gibt es im FAT32?Dateisystem keine Dateinummern (inode
number), an der eine Datei vom Synchronisations? oder
Backup?Programm wiedererkannt werden kann.

Mein Verdacht: FAT32?Dateisysteme sind in der Linuxwelt für
Synchronisation oder Backup nicht geeignet.

Um 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
folgendes zu probieren:

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ängeihn
erneut ein.

Führe jetzt die zwei genannten ?ls??Kommandos erneut aus.

Poste bitte die Ausgaben aller 4 ?ls??Kommandos.

(Sollte sich der Verdacht erhärten, wäre möglicherweise ein
Wechsel ins Newsgroup ?de.comp.os.unix.linux.misc? oder gar
?de.comp.os.unix.programming? sinnvoll, wenn das Problem mit FAT32
und POSIX unabhängig von Unison weiter diskutiert werden soll.)
Werner Holtfreter (21.07.2018, 00:42)
Helmut Waitzmann wrote:

> Werner Holtfreter <holtfreter>:
> Hattest Du Unison auf dem LinuxPC vor dem Einhängen des
> USB?Ansteckspeichers beendet?


Ja.

<https://de.wikipedia.org/wiki/Unison_%28Software%29#Funktionsweise>
> legt nahe, dass das nötig ist:
> Unison prüft nach dem Start den Dateibestand pro Verzeichnis
> bzw. Computer und vergleicht die Zeitstempel der Dateien. Stellt
> es Veränderungen fest, werden die Änderungen der entsprechenden
> Dateien genauer analysiert. Danach erstellt Unison eine
> Replikationsliste mit Vorschlägen für deren Synchronisation und
> markiert nicht automatisch auflösbare Konflikte.
> Unison auf dem LinuxPC schlägt also vor, ?alt.xls? vom
> USB?Ansteckspeicher auf den LinuxPC zu kopieren?


Ja.

> ?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.

>>jetzt 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.

Nach Reboot immer noch das gleiche Bild:

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. (Gleiches Verhalten übrigens mit einer
PDF-Datei, das Verhalten ist also nicht an .xls gebunden.)

[..]
> erneut ein.
> Führe jetzt die zwei genannten ?ls??Kommandos erneut aus.
> Poste bitte die Ausgaben aller 4 ?ls??Kommandos.


werner@zuse:/media/werner/8427-B0C8$ touch test.txt
werner@zuse:/media/werner/8427-B0C8$ ls -ldogic -- test.txt
6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
werner@zuse:/media/werner/8427-B0C8$ ls -ldogi -- test.txt
6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
werner@zuse:/media/werner/8427-B0C8$ echo blabla >> test.txt
werner@zuse:/media/werner/8427-B0C8$

werner@zuse:/media/werner/8427-B0C8$ ls -ldogic -- test.txt
6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
werner@zuse:/media/werner/8427-B0C8$ ls -ldogi -- test.txt
6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
werner@zuse:/media/werner/8427-B0C8$

Beide Zeitinfos haben sich demnach geändert.

Der 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.

Wenn wir die Ursache nicht finden, kann ich auf dem USB-Stick auch
ein anderes Dateisystem installieren - welches empfiehlst du? Aber
schöner wäre es, zunächst die Ursache zu finden.

Danke für deine Hilfe.
Helmut Waitzmann (21.07.2018, 19:16)
Werner Holtfreter <holtfreter>:
>Helmut Waitzmann wrote:
>> Werner Holtfreter <holtfreter>:


>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.

>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.

>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? aufdem
LinuxPC auf den USB?Ansteckspeicher kopieren (und dabei die
anscheinend neue Fassung auf dem Ansteckspeicher überschreiben)?
Das ist in der Tat sehr seltsam.

>Naja, eigentlich ist sie ja dort auch neu.
>Nach Reboot immer noch das gleiche Bild:
>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).

[?]

>werner@zuse:/media/werner/8427-B0C8$ touch test.txt
>werner@zuse:/media/werner/8427-B0C8$ ls -ldogic -- test.txt
>6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
>werner@zuse:/media/werner/8427-B0C8$ ls -ldogi -- test.txt
>6689 -rw-r--r-- 1 0 Jul 21 00:29 test.txt
>werner@zuse:/media/werner/8427-B0C8$ echo blabla >> test.txt
>werner@zuse:/media/werner/8427-B0C8$


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.

>werner@zuse:/media/werner/8427-B0C8$ ls -ldogic -- test.txt
>6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
>werner@zuse:/media/werner/8427-B0C8$ ls -ldogi -- test.txt
>6696 -rw-r--r-- 1 7 Jul 21 00:30 test.txt
>werner@zuse:/media/werner/8427-B0C8$
>Beide Zeitinfos haben sich demnach geändert.


Das beweist immerhin, dass Linux den Zeitpunkt der Dateierstellung
nicht als Zeitpunkt der letzten Dateizustandsänderung
missversteht.

>Der 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.

>Wenn 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.

>Aber 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.
Werner Holtfreter (21.07.2018, 22:47)
Helmut Waitzmann wrote:

[..]
> 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.


Ich bin nur sicher, dass ich keinen Befehl zur Speicherung gegeben
habe bzw. eventuelle Nachfragen beim Schließen mit Nein beantwortet
habe.

> 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.


Aber in gewisser Weise auch konsequent, denn Unison hat die Datei
auf dem USB-Stick ja gar nicht als existent erkannt.

> 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).
> [?]


Dieser Teil des Problems, nämlich dass eine Datei überflüssiger
Weise noch einmal transferiert werden soll, ist nicht schlimm.

Schlimm und mit Dateiattributen nicht erklärbar ist, dass eine neue
Datei nicht erkannt und folglich nicht synchronisiert wird.

[..]
> Fehler bei Unison vorstellen. (Du hast bisher nichts dazu
> geschrieben, wie Du Unison konfiguriert hast, und nichts dazu, wie
> Du es aufgerufen hast.)


Auf dem LinuxPC habe ich es aus den Repos installiert und nur die zu
synchronisierenden Dateipfade angegeben. Ich starte es über die
grafische Oberfläche (hier der Trinity-Desktop des Debian-Derivats
Q4OS).

Auf dem Win7PC fehlten für die reguläre Installation einige
Bibliotheken, deshalb habe ich dort eine "mobile" Version abgelegt,
die alle Bibliotheken an Bord hat. Auch dort habe ich nur die
Dateipfade vorgegeben. Da ebenfalls Start durch einen Klick auf
einen Link zur betreffenden Startdatei im Verzeichnis des mobilen
Unison.

[..]
> Vergangenheit, Gegenwart und Zukunft gesetzt werden. Daran zu
> entscheiden, ob eine Datei archiviert oder synchronisiert werden
> muss, ist nicht verlässlich möglich.


Lies den 2. Absatz richtig: Eine überflüssige Synchronisierung ist
möglich, aber eine versäumte ist ausgeschlossen. Was dann über
Zeitstempel folgt, bezieht sich anscheinend auf mutwillige
Täuschung. (Denkbar wäre auch eine verstellte Rechneruhr.)

> Dazu kommt, dass FAT32 keine inode numbers hat. Die werden aber
> laut dem angeführten Zitat von Unison bei Unix zwingend gebraucht.
> 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.)


Ja, an diese Dateisysteme hatte ich auch gedacht. Aber die
Zeitstempel sind nachrangig, wenn noch nicht einmal komplett neue
Dateien erkannt werden.

> 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.


Das hätte ja nur Sinn, wenn nicht das ganze Archiv bei Änderungen
neu geschrieben werden müsste, wie es bei ZIP und TAR der Fall sein
dürfte.

Bisher habe ich am Ende des Tages den ganzen Dateibaum kopiert. Das
funktioniert, dauert aber lange und stresst des Flash-Speicher.

>>Aber 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.


Die beschriebenen Unzulänglichkeiten erklären nur überflüssige
Syncs, aber keine unterlassenen. Wenn niemanden etwas einfällt,
werde ich ein anderes Dateisystem auf dem USB-Stick probieren,
obwohl das leider nur ein Stochern im Nebel ist.
Helmut Waitzmann (21.07.2018, 23:46)
Werner Holtfreter <holtfreter>:
>Helmut Waitzmann wrote:


><https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#updates>
>(<https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#caveats>)
>Lies den 2. Absatz richtig: Eine überflüssige Synchronisierung ist
>möglich, aber eine versäumte ist ausgeschlossen. Was dann über
>Zeitstempel folgt, bezieht sich anscheinend auf mutwillige
>Täuschung. (Denkbar wäre auch eine verstellte Rechneruhr.)


Ich lese ihn richtig. Betrachte folgendes Szenario:

Man hat eine Datei, etwa ?Datei.txt? geändert. Der Texteditor
hat dabei sicherheitshalber die bisherige Fassung in
?Datei.bak? umbenannt, damit sie noch verfügbar ist, sollte sie
nochmal gebraucht werden. Danach hat man beide Fassungen mit
Hilfe von Unison auch woanders hin synchronisiert.

Jetzt stellt sich heraus, dass die Änderung doch keine gute Idee
war. Also holt man die alte Fassung wieder hervor mit dem
Kommando

mv -f -- Datei.bak Datei.txt

und nimmt anschließend Unison her, um diese Rücknahme der Änderung
zu synchronisieren. Ein ungewöhnliches Szenario? Ich denke,
nicht.

Was wird Unison jetzt tun?
Helmut Waitzmann (21.07.2018, 23:53)
Werner Holtfreter <holtfreter>:
>Helmut Waitzmann wrote:


>Das hätte ja nur Sinn, wenn nicht das ganze Archiv bei Änderungen
>neu geschrieben werden müsste, wie es bei ZIP und TAR der Fall sein
>dürfte.


Das vermeidet man im Allgemeinen mit incremental backups. Da wird
Unverändertes nicht nochmal archiviert.
Werner Holtfreter (22.07.2018, 01:47)
Helmut Waitzmann wrote:

[..]
> zu synchronisieren. Ein ungewöhnliches Szenario? Ich denke,
> nicht.
> Was wird Unison jetzt tun?


Daran hatte ich nicht gedacht, die Bedenken sind berechtigt. Ich
habe es ausprobiert:

Datei erzeugt auf dem LinuxPC
Geändert mit Backupdatei - geachtet auf gleiche Dateigröße
Sync auf USB-Stick, Stick abgezogen
Auf LinuxPC mv -f -- Datei.bak Datei.txt
Sync auf USB-Stick

Ergebnis: Korrekte(!) Arbeitsweise, lediglich das Dateidatum auf dem
USB-Stick entsprach nicht der Zeit von Datei.bak sondern der Zeit
des Kopiervorgangs.

Stick abgezogen, angesteckt, erneut Sync: Diesmal wurde die mit
neuerer Zeit auf dem USB-Stick befindliche Datei (zurück) zum
LinuxPC kopiert. Abermals erhielt die Kopie die Zeit der
Kopieraktion.

Stick abgezogen, angesteckt, erneut Sync: Diesmal wurde kein
Sync-Bedarf angezeigt, obwohl die Zeitstempel der beteiligten
Dateien unterschiedlich sind.

Im letzten Schritt wurde auch der Löschvorgang auf dem USB-Stick
korrekt auf den LinuxPC synchronisiert.

Ich nehme an, dass Unison eine Datenbank zu den beteiligten Dateien
pflegt, deshalb hat das hier relativ gut geklappt. Wenn man
abwechselnd mit dem Unison auf dem LinuxPC und auf dem Win7PC
arbeitet, steht natürlich die letzte Info nicht zur Verfügung.

Im Grunde synchronisiere ich ja drei Speicher, und diese in Reihe.
Das Handbuch empfiehlt jedoch eine Sternkonfiguration:

*Using Unison to Synchronize More Than Two Machines*

Unison is designed for synchronizing pairs of replicas. However, it
is possible to use it to keep larger groups of machines in sync by
performing multiple pairwise synchronizations.

If you need to do this, the most reliable way to set things up is to
organize the machines into a ?star topology,? with one machine
designated as the ?hub? and the rest as ?spokes,? and with each
spoke machine synchronizing only with the hub. The big advantage of
the star topology is that it eliminates the possibility of
confusing ?spurious conflicts? arising from the fact that a
separate archive is maintained by Unison for every pair of hosts
^^^^^^^^^^^^^^^^
that it synchronizes.

Besser wäre es, wenn das Archiv auf dem USB-Stick liegen würde. Das
mobile Unison könnte ich auf dem USB-Stick installieren, nur müsste
das dann auf dem LinuxPC unter Wine laufen. Neue Komplikationen,
die ich mir nicht antun will.
Ähnliche Themen