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

[Michael von Glasow]

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.

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?

On 19/01/2025 15:56, Dan Christensen wrote:
> I think it would be a mistake to auto-update times to the older one.  If
> a timestamp has been updated, then if anything automatic happens, it
> should be that the older timestamp is replaced by the newer one.

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

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. (Maybe even add an
explicit warning if timestamp-only conflicts have been detected and the
archive is from an older version.)

> For example, make's behaviour depends on timestamps.  Suppose we have
> file1.c producing file1.o, with the replicas in sync (including times).
>
> I edit file1.c and rebuild file1.o, but then realize that there's a bug.
> So I revert my change to file1.c, but don't get around to running make.
> Then I run unison, and the timestamp on file1.c gets set to the old
> time, since the file contents match.  Then I run make, and file1.o is
> *not* updated, and I can't figure out why the program is still buggy.
IMHO that would be a rather exotic use case for Unison. Standard
procedure is to use version control. When reverting to an earlier
version, the VCS should set the timestamp to when the file was reverted,
not when it was first created in this version – I’m fairly sure this is
what Git and others do.
> Other software also relies on timestamps.  E.g. a lock file is often
> empty, but the timestamp is sometimes used to indicate whether the lock
> is stale.
If you actually have a use case for syncing lock files, I’d be inclined
to assume that, for the purpose of determining whether a lock is stale,
you would want the timestamp to be lock acquisition time, not lock sync
time. times=false doesn’t seem very well suited to lock files which
expire based on their timestamp.
> (I use times=yes, so this wouldn't affect me.  I'm just arguing that
> automatic conflict resolution to the older time is not safe and should
> not be something that happens without the user selecting it and being
> warned that it is not safe.)
See above – if legacy discrepancies in times become conflicts and must
be resolved manually, or the discrepancy is left alone until the next
actual change on either side, this should not be much of an issue.