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

[Tõivo Leedjärv]

On Sun, 19 Jan 2025 at 19:37, Michael von Glasow <michael at vonglasow.com> wrote:
>
> Issues, if any, would be mostly limited to the transition period from
> implicit times=false to implicit times=true, as the first transition
> with the new default might change timestamps to older ones (time when
> the original file was modified rather than the time at which it was
> propagated to the other root). However, this should only turn back time
> on files which have not been updated. Modified files would have
> timestamps which are later than the last sync, and that’s what would get
> propagated, save for some exotic corner cases.

This is my understanding, too. This situation really should not arise
during normal syncs.

> It has been pointed out that this might cause issues with FAT
> filesystems. Unison has the fat option, which implies a few workarounds
> for limitations of the FAT filesystem (perms=0, dontchmod=true,
> ignorecase=true, links=false, ignoreinodenumbers=true). If we decide to
> make times=true the default, would it make sense to redefine fat=true to
> also imply times=false?

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.

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

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

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