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

[Doros Eracledes]

Isn't this what the -prefer option does ?
I used it when the date has changed on both sides but the files are the same.

Best
Doros
________________________________
From: Unison-hackers <unison-hackers-bounces at LISTS.SEAS.UPENN.EDU> on behalf of Tõivo Leedjärv <toivol at gmail.com>
Sent: 20 January 2025 10:38 AM
To: unison-hackers at lists.seas.upenn.edu <unison-hackers at lists.seas.upenn.edu>
Subject: Re: [Unison-hackers] On making times=true the default

On Sun, 19 Jan 2025 at 19:37, Michael von Glasow <michael at vonglasow.com> wrote:
>
> 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.

This is my understanding, too. This situation really should not arise
during normal syncs.

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

I would like to avoid it, if reasonably possible. This option is also
not a true indicator if a FAT filesystem is involved or not.

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

Unison will report a time change in both replicas and present it as a
conflict since the times differ.

Without any changes to the code, nothing else would happen. This is a
conflict that needs to be resolved by the user.

According to my understanding of Greg's proposal, the conflict could
be automatically resolved by proposing a propagation direction to the
user. Nothing would/should be propagated automatically, though, unless
running in batch/repeat mode.

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

Right. Just one thing to keep in mind is that the number of conflicts
could be very large, depending on replica size.

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

Yes, I believe we'd have to have such a warning.
_______________________________________________
Unison-hackers mailing list
Unison-hackers at LISTS.SEAS.UPENN.EDU
https://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Flists.seas.upenn.edu*2Fmailman*2Flistinfo*2Funison-hackers&data=05*7C02*7Cd.eracledes*40albourne.com*7C2fedefbeb479458cdb7008dd392dedc3*7C9d1f0723d7114aabb0a87780c86185f2*7C0*7C0*7C638729591620257026*7CUnknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C4000*7C*7C*7C&sdata=6f419iu2bUIOtcsVwZe4JtjXRwAypAzYz0iJx25yl0s*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!IBzWLUs!VswzWXMK53Z0YPDjDNeKcD3RMN2A8WWnGgYYQT41QYGKNwgXPDtZ4eD4ZS8P83Z4PCGDc7nTf_5t_q1-nc5ZkEvxuMfuidDrB4qC$ <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/20250120/dbe7668c/attachment-0001.htm>