Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.software.misc > #114

Re: Unison Synchronisationsprobleme

Show all headers | View raw

Werner Holtfreter <holtfreter@gmx.de>:

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

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 sich auf
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änge ihn
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.)

Back to de.comp.software.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Unison Synchronisationsprobleme Werner Holtfreter <holtfreter@gmx.de> - 2018-07-20 10:26 +0200
  Re: Unison Synchronisationsprobleme Helmut Waitzmann <nn.throttle@xoxy.net> - 2018-07-20 23:19 +0200
    Re: Unison Synchronisationsprobleme Werner Holtfreter <holtfreter@gmx.de> - 2018-07-21 00:42 +0200
      Re: Unison Synchronisationsprobleme Helmut Waitzmann <nn.throttle@xoxy.net> - 2018-07-21 19:16 +0200
        Re: Unison Synchronisationsprobleme Werner Holtfreter <holtfreter@gmx.de> - 2018-07-21 22:47 +0200
          Re: Unison Synchronisationsprobleme Helmut Waitzmann <nn.throttle@xoxy.net> - 2018-07-21 23:46 +0200
            Re: Unison Synchronisationsprobleme Werner Holtfreter <holtfreter@gmx.de> - 2018-07-22 01:47 +0200
          Re: Unison Synchronisationsprobleme Helmut Waitzmann <nn.throttle@xoxy.net> - 2018-07-21 23:53 +0200

csiph-web