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

[Benjamin Pierce]

FWIW, I'm a little nervous about changing defaults on something so
fundamental.

E.g., we can be careful not to do it when using old archives where times
have not been synced, but what if those archives get blown away and the
user expects to be able to just run unison again to recreate them from
scratch?  This is something some people might be quite surprised by.

I wonder if there is a less intrusive way.  E.g., what about adding a new
preference -notimesnowarn, default false, and printing a warning if -times
and -reallynotimes are both false, along the lines of "We notice you have
-times set to false; we recommend setting it to true, but if you have a
good reason for keeping it false, you can suppress this warning by setting
-notimesnowarn to true"?

On Thu, Jan 16, 2025 at 8:43 AM Greg Troxel <gdt at lexort.com> wrote:

> 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.
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at LISTS.SEAS.UPENN.EDU
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20250116/1008badf/attachment.htm>