Re: On making times=true the default

On Thu, 16 Jan 2025 at 14:42, Greg Troxel <[email protected]> wrote:
>
> 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".

I'm not sure it needs to go as far as setting times off. As far as I
understand, syncing times on FAT mostly works. Recently the code for
ignoring 1 hour time differences was removed. This is mainly what I'd
expect to break for FAT users twice a year, should times be synced by
default.

It could be possible to detect that the filesystem is FAT and then
re-introduce the code ignoring 1 hour differences just for FAT
replicas. I don't know if FAT detection is possible or not. I'd expect
it to be possible in Windows, not sure about Unix/Linux.

> 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 think this makes sense and is probably a good idea to implement
regardless of the default setting. However, speaking of nasty
surprises for existing users, this does not remove the potentially
very large number of updates the first time they run the new version
with the changed default. It removes the time conflicts, but the list
of update items would still be present and need to be reviewed by the
user (depending on their preferences). It can still be quite
confusing.

Details on how to deal with conflicts involving non-time updates also
need to be worked out. For example, file contents changed in one
replica, time changed in other replica (due to change of default or
otherwise). This might be an issue with busy replicas as the first
sync after version upgrade could still yield many conflicts. Of
course, syncing with the old version just before upgrading would
mostly relieve this, too.

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

This should be easily doable. I'm not against the idea. Not having
thought about it futher, right now I I'd say I even prefer it, for
freedom of choice.

> With auto conflict, I don't think it's trouble.  It is possible someone
[...]
>
> Yes, but I think this calls for auto-resolve to oldest.

Keep in mind that any change would conflict. Auto-resolve would only
resolve conflicts where just the mtime has changed in both replicas.