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

[Greg Troxel]

Dan Christensen <jdc at uwo.ca> writes:

> On Jan 20, 2025, Tõivo Leedjärv <toivol at gmail.com> wrote:
>
>> On Sun, 19 Jan 2025 at 14:56, Dan Christensen <jdc at uwo.ca> wrote:
>>>
>>> On Jan 16, 2025, Greg Troxel <gdt at lexort.com> wrote:
>>>
>>> > 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 think it would be a mistake to auto-update times to the older one.  If
>>
>> I don't know if that's what Greg meant, but my reading of his idea,
>> and my reply, was that this is just automatic conflict resolution, not
>> automatic propagation (which I would not support).
>
> Greg used the word "silent" above, and that's what I'm objecting to.
> I don't object as strongly if the propagation is not automatic,
> although I'm still not sure why choosing the older time would be
> the best choice.  Time stamps are often used to indicate changes,
> and to me the most recent time would make the most sense.

I really did mean silent, but I see why people object and we'll need a
plan that is widely viewed as reasonable.

(In all of this I am assuming filesystems that work correctly with
respect to mtimes, being able to set mtime, and later read it back and
get the value that was written.  Dealing with FAT (only FAT?) is I hope
separable.)

Fundamentally where I'm coming from is that many people have been
syncing directories, and they've been quite reasonably using the
defaults, and thus not syncing mtimes.  I view the lack of syncing times
by default as a bug, and that we are now fixing that bug.

As part of fixing the bug, I would like for people to be able to get to
the state that they would have been in, had there been no bug, with
almost no difficulty and reasonable effort.  Dealing with
conflicts/updates on a per-file basis does not seem reasonable.

I said older, because I believe that in a existing replica pair, if a
file has different times, it is because that when it was first written
by the user, it had a time, and then unison copied it to the other
replica, resulting in a newer mtime.  I view the loss of the original
mtime as serious, and view setting the newer one back as a repair.

I can see a sequence
  create on A
  sync to B
  touch on B
  sync to A

but then, presumably B's time will be less than A's.  Can anyone see
how, assuming 

  unison operated with times=false before
  replicas were fully synced before upgrade*

choosing older will get the wrong value, meaning different from the
value that would have existed if all previous syncs had times=yes?

* We do not document as a requirement that people sync before upgrade,
  but I think it's a best practice to do so, and asking for trouble not
  to do so.  So I am most concerned about what happens to people who do
  sync before upgrade, although those who don't should get reasonable
  behavior.

> Thanks for also pointing out that my example involving make wouldn't
> involve a conflict, and so the above wouldn't apply.  But I still
> think there are situations in which it would and that we should make
> it safe to run unison without worrying about information loss.

The comments make me think that while I personally would welcome, for
files that are not in need of syncing except for mtime, silent
adjustment of mtime to older, there are people that don't like this.

I therefore think we could have

  times=on: sync mtimes, with no special accomodations, so what happens
    is as today if you just flip the preference

  times=off: as now by default

  times=repair: for files which would not appear in the resolution
    output if times were off, and which differ in mtime, change the
    mtime of the newer one to the older one

and then people could, after upgrading, either

  set times=off to not change

  est times=on and deal manually

  set times=repair and sync all their replicas, and then undo that

I don't have a really strong opinion about true silence vs something, as
long as there is no list of files that are getting this treatment, and
only one or two prompts to do it, even for a replica with 100K files.  I
expect that for people coming from times=false to true, that essentially
every file will need a time change, on every replica pair.

If we didn't have times=repair, people might want to rsync their
replicas, and that feels like trouble.

I see now that times=repair as a lasting mode is undesirable.  I now
think it should be limited to recovery from the "times=false bug".


(I should note that my personal usage of unison is perhaps unusual, and
this is surely coloring my opinions:

  I've been using dump/restore and rsync to upgrade/replace disks, so I
  have old mtimes.  Looking quickly, I found November 13, 1984 (on an
  SSD bought in 2023).

  I don't sync source code; I use CVS or git.  (I remember when CVS was
  a really cool thing that was better than RCS with the ,v files
  accessed via NFS!)

  I don't sync my whole homedir.

  I have a bunch of directories shared/foo, and they are logical
  collections in terms of content, and each foo has a set of machines
  that it is synced among, essentially always hub and spoke.  Gradually
  I put stuff in there as I organize it.

This is a long way of explaining that for me, the oldest timestamp among
any replica is the right one.)


If someone has converted from times=false to times=true, for a replica
with more files than they can stand to think about individually, a trip
report about the experience would be interesting.