[Unison-hackers] On making times=true the default

[Greg Troxel]

Tõivo Leedjärv <toivol at gmail.com> writes:

> I would like to avoid it, if reasonably possible. This option is also
> not a true indicator if a FAT filesystem is involved or not.

It would be great from someone who uses FAT with unison to experiment
with times=yes across timezone/DST changes.  I am unclear on if
converting unix time to filesystem time is done in the DST-or-not TZ of
the host, or done in the context of e.g. "PST8PDT", "GMT0BST".  The
question (northern centric) is if, in July, writing a time in January,
the unix timeval (UTC) is converted as if DST is in effect or not.  If
it's only times that are in the hour surrounding DST changes, it's
probably not a big deal.  If all winter times change come DST, it's a
much bigger problem.

  
>> What would happen when syncing two roots with times=false and then,
>> without making any changes, repeating the operation with times=true?
>> Between the two sync operations, timestamps would differ (last
>> modification time in the root where the file originated, sync time in
>> the other). Would that be detected at all, or would Unison, having
>> marked the two files as identical, consider them unchanged as long as
>> their content and timestamp is as last synced? If this is reported as a
>> change, would Unison consider it a conflict, or would it consider it an
>> update on one side and propagate automatically (and in what direction)?
>
> Unison will report a time change in both replicas and present it as a
> conflict since the times differ.
>
> Without any changes to the code, nothing else would happen. This is a
> conflict that needs to be resolved by the user.
>
> According to my understanding of Greg's proposal, the conflict could
> be automatically resolved by proposing a propagation direction to the
> user. Nothing would/should be propagated automatically, though, unless
> running in batch/repeat mode.

I meant "consider this not a conflict, but a repair of an earlier
incorrect sync".

>> If timestamp discrepancies from introducing times=yes are considered
>> conflicts, this might be the easiest scenario: users get warned and can
>> still take action before Unison makes any changes.
>
> Right. Just one thing to keep in mind is that the number of conflicts
> could be very large, depending on replica size.

I would expect one conflict per file.  Unless the replica was created by
rsync and then running unison, but that's odd.

>> (Maybe even add an
>> explicit warning if timestamp-only conflicts have been detected and the
>> archive is from an older version.)
>
> Yes, I believe we'd have to have such a warning.

Perhaps, this can be addressed by detecting that situation, prompting
once

  For all files that have timestamp-only differences, set the timestamp
  of the newer file to the timestamp of the older file?  [y/N]

and if yes, update timestamps, and then restart/resume sync.