<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Isn't this what the -prefer option does ?</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I used it when the date has changed on both sides but the files are the same. </div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best</div>
<div style="direction: ltr; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Doros</div>
<div id="x_appendonsend"></div>
<hr style="direction: ltr; display: inline-block; width: 98%;">
<div dir="ltr" id="x_divRplyFwdMsg"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Unison-hackers <unison-hackers-bounces@LISTS.SEAS.UPENN.EDU> on behalf of Tõivo Leedjärv <toivol@gmail.com><br>
<b>Sent:</b> 20 January 2025 10:38 AM<br>
<b>To:</b> unison-hackers@lists.seas.upenn.edu <unison-hackers@lists.seas.upenn.edu><br>
<b>Subject:</b> Re: [Unison-hackers] On making times=true the default</span>
<div> </div>
</div>
<div style="direction: ltr; font-size: 11pt;">On Sun, 19 Jan 2025 at 19:37, Michael von Glasow <michael@vonglasow.com> wrote:<br>
><br>
> Issues, if any, would be mostly limited to the transition period from<br>
> implicit times=false to implicit times=true, as the first transition<br>
> with the new default might change timestamps to older ones (time when<br>
> the original file was modified rather than the time at which it was<br>
> propagated to the other root). However, this should only turn back time<br>
> on files which have not been updated. Modified files would have<br>
> timestamps which are later than the last sync, and that’s what would get<br>
> propagated, save for some exotic corner cases.<br>
<br>
This is my understanding, too. This situation really should not arise<br>
during normal syncs.<br>
<br>
> It has been pointed out that this might cause issues with FAT<br>
> filesystems. Unison has the fat option, which implies a few workarounds<br>
> for limitations of the FAT filesystem (perms=0, dontchmod=true,<br>
> ignorecase=true, links=false, ignoreinodenumbers=true). If we decide to<br>
> make times=true the default, would it make sense to redefine fat=true to<br>
> also imply times=false?<br>
<br>
I would like to avoid it, if reasonably possible. This option is also<br>
not a true indicator if a FAT filesystem is involved or not.<br>
<br>
> What would happen when syncing two roots with times=false and then,<br>
> without making any changes, repeating the operation with times=true?<br>
> Between the two sync operations, timestamps would differ (last<br>
> modification time in the root where the file originated, sync time in<br>
> the other). Would that be detected at all, or would Unison, having<br>
> marked the two files as identical, consider them unchanged as long as<br>
> their content and timestamp is as last synced? If this is reported as a<br>
> change, would Unison consider it a conflict, or would it consider it an<br>
> update on one side and propagate automatically (and in what direction)?<br>
<br>
Unison will report a time change in both replicas and present it as a<br>
conflict since the times differ.<br>
<br>
Without any changes to the code, nothing else would happen. This is a<br>
conflict that needs to be resolved by the user.<br>
<br>
According to my understanding of Greg's proposal, the conflict could<br>
be automatically resolved by proposing a propagation direction to the<br>
user. Nothing would/should be propagated automatically, though, unless<br>
running in batch/repeat mode.<br>
<br>
> If timestamp discrepancies from introducing times=yes are considered<br>
> conflicts, this might be the easiest scenario: users get warned and can<br>
> still take action before Unison makes any changes.<br>
<br>
Right. Just one thing to keep in mind is that the number of conflicts<br>
could be very large, depending on replica size.<br>
<br>
> (Maybe even add an<br>
> explicit warning if timestamp-only conflicts have been detected and the<br>
> archive is from an older version.)<br>
<br>
Yes, I believe we'd have to have such a warning.<br>
_______________________________________________<br>
Unison-hackers mailing list<br>
Unison-hackers@LISTS.SEAS.UPENN.EDU<br>
<a href="https://lists.seas.upenn.edu/mailman/listinfo/unison-hackers" id="OWAf2b03baa-d1aa-55d3-74d3-1971c0ceae0d" class="OWAAutoLink" data-auth="NotApplicable">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</a></div>
</body>
</html>