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

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

Re: Unison Synchronisationsprobleme

Show all headers | View raw

Werner Holtfreter <holtfreter@gmx.de>:
>Helmut Waitzmann wrote:

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

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