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

[Greg Troxel]

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

> TL;DR I'd like to get your opinions and ideas on two questions: 1) Do
> you think times=true should be the default? 2) If yes, any suggestions
> on how to manage existing users?

I lean to making it default.  I realize this is preference, but I use
'rsync -av', and I expect unison to be like that.  Another view is that
unison replicas are kind of like a distributed filesystem, and mtimes
are simply part of that.

> I think the main counter-arguments have been two-fold:
>
>   1) FAT filesystems may cause trouble. How real is this issue? Would
>      there be trouble (if at all) only at DST changes or any time?

> I don't know how serious the issue with FAT filesystems is, but is it
> sufficient to dictate a default preference for everyone? Likely not.

My view is that FAT is a special case, and that FAT has time problems in
general.  It would make sense for people using them to set times off,
maybe, and perhaps that could be part of "-fat".  But I don't want to
mess up people that mitigate FAT's time bugs by setting their machines
to UTC.  I also don't really want to add kludges for it, at least not
kludges that would affect anybody not asking for FAT kludges.

I don't think it's reasonable to have people with non-deficient
filesystems default off because of a deficient filesystem.

>   2) Existing users would get a nasty surprise as potentially their
>      entire replicas would be listed as conflicts due to different
>      mtimes.

> As for managing the change for existing users, I'm thinking the solution
> might be to earmark all the archives that are created after this change
> of default. Then, when loading archives without this mark, and the user
> hasn't specified the times preference, we'd set times=false again. This
> way, all the new users will get the new default, all the existing users
> will not get a nasty surprise, and all users explicitly setting the times
> preference won't be affected either way.

That's interesting, but I wonder if this can be easier for people.

I would say that often there are existing copies of files, intended to
be mostly the same.  This could be replicas previously synced by unison
with archive state, by rsync, or by unison but the archive state has
been lost.  In all these cases, the mtimes (on files) *ought* to be the
same, and it's more or less a bug if they aren't.

The nature of syncing, by mechanisms that don't sync times, is that the
source as the old/original mtime, and the destination has a new mtime
(at time of sync).

So, I would be in favor of times=yes having automatic/silent conflict
resolution where the newer timestamp is set to the older one, as fixing
up past errors.

I can conceive that someone wouldn't want this, even though I am not
sure any actual people don't want it.  So we could have times=no,
times=yes (no auto-conflict-fi), and times=auto (sync, and auto-resolve
to older).

I'm not sure how difficult this is to deal with.  I'm just thinking in
terms of what would be nice.

> Finally, will this new default cause too much confusion? While I think
> it would be the correct default, and should work well for hopefully
> most users, it comes with a risk of confusing and frustrating users in
> some specific situations.

With auto conflict, I don't think it's trouble.  It is possible someone
is relying on copies having newer mtimes, but we can simply ask on users
and hearing nothing, just have it in NEWS.  I don't want to pull the rug
out from under people, but if we ask and hear nothing, that's as much as
can reasonably be done.

> Whenever a user starts syncing two new already-populated replicas, or
> re-creates some existing archives (either by choice or by having lost
> their archives), they may still get a ton of conflicts. This, I hope,
> is acceptable because they can then explicitly set times=false if they
> wish. When creating new archives and noticing many props conflicts,
> Unison could even display a message hinting the user about this
> preference.

Yes, but I think this calls for auto-resolve to oldest.