Re: On making times=true the default
Doros Eracledes <[email protected]> Mon, 20 Jan 2025 09:37:33 +0000
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <DB9PR09MB68117D82472646E7A75D3A2D9DE72@DB9PR09MB6811.eurprd09.prod.outlook.com> |
--===============0768528289999987431== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_DB9PR09MB68117D82472646E7A75D3A2D9DE72DB9PR09MB6811eurp_" --_000_DB9PR09MB68117D82472646E7A75D3A2D9DE72DB9PR09MB6811eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Isn't this what the -prefer option does ? I used it when the date has changed on both sides but the files are the sam= e. Best Doros ________________________________ From: Unison-hackers <[email protected]> on behal= f of T=F5ivo Leedj=E4rv <[email protected]> Sent: 20 January 2025 10:38 AM To: [email protected] <[email protected]= u> Subject: Re: [Unison-hackers] On making times=3Dtrue the default On Sun, 19 Jan 2025 at 19:37, Michael von Glasow <[email protected]> wr= ote: > > Issues, if any, would be mostly limited to the transition period from > implicit times=3Dfalse to implicit times=3Dtrue, 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=92s 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=3D0, dontchmod=3Dtrue, > ignorecase=3Dtrue, links=3Dfalse, ignoreinodenumbers=3Dtrue). If we decid= e to > make times=3Dtrue the default, would it make sense to redefine fat=3Dtrue= to > also imply times=3Dfalse? 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=3Dfalse and then, > without making any changes, repeating the operation with times=3Dtrue? > 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=3Dyes 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 [email protected] https://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/= ?url=3Dhttps*3A*2F*2Flists.seas.upenn.edu*2Fmailman*2Flistinfo*2Funison-hac= kers&data=3D05*7C02*7Cd.eracledes*40albourne.com*7C2fedefbeb479458cdb7008dd= 392dedc3*7C9d1f0723d7114aabb0a87780c86185f2*7C0*7C0*7C638729591620257026*7C= Unknown*7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa= W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ*3D*3D*7C4000*7C*7C*7C&sdata=3D6f419iu2bUI= OtcsVwZe4JtjXRwAypAzYz0iJx25yl0s*3D&reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJSUl= JSUlJSU!!IBzWLUs!VswzWXMK53Z0YPDjDNeKcD3RMN2A8WWnGgYYQT41QYGKNwgXPDtZ4eD4ZS= 8P83Z4PCGDc7nTf_5t_q1-nc5ZkEvxuMfuidDrB4qC$ <https://lists.seas.upenn.edu/m= ailman/listinfo/unison-hackers> --_000_DB9PR09MB68117D82472646E7A75D3A2D9DE72DB9PR09MB6811eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> </div> <div style=3D"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=3D"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 sam= e. </div> <div style=3D"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=3D"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=3D"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=3D"x_appendonsend"></div> <hr style=3D"direction: ltr; display: inline-block; width: 98%;"> <div dir=3D"ltr" id=3D"x_divRplyFwdMsg"><span style=3D"font-family: Calibri= , sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> Unis= on-hackers <[email protected]> on behalf of= T=F5ivo Leedj=E4rv <[email protected]><br> <b>Sent:</b> 20 January 2025 10:38 AM<br> <b>To:</b> [email protected] <unison-hackers@list= s.seas.upenn.edu><br> <b>Subject:</b> Re: [Unison-hackers] On making times=3Dtrue the defaul= t</span> <div> </div> </div> <div style=3D"direction: ltr; font-size: 11pt;">On Sun, 19 Jan 2025 at 19:3= 7, Michael von Glasow <[email protected]> wrote:<br> ><br> > Issues, if any, would be mostly limited to the transition period from<= br> > implicit times=3Dfalse to implicit times=3Dtrue, as the first transiti= on<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 tim= e<br> > on files which have not been updated. Modified files would have<br> > timestamps which are later than the last sync, and that=92s 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 workaround= s<br> > for limitations of the FAT filesystem (perms=3D0, dontchmod=3Dtrue,<br= > > ignorecase=3Dtrue, links=3Dfalse, ignoreinodenumbers=3Dtrue). If we de= cide to<br> > make times=3Dtrue the default, would it make sense to redefine fat=3Dt= rue to<br> > also imply times=3Dfalse?<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=3Dfalse and then,<= br> > without making any changes, repeating the operation with times=3Dtrue?= <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 a= n<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=3Dyes are considered= <br> > conflicts, this might be the easiest scenario: users get warned and ca= n<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 th= e<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> [email protected]<br> <a href=3D"https://lists.seas.upenn.edu/mailman/listinfo/unison-hackers" id= =3D"OWAf2b03baa-d1aa-55d3-74d3-1971c0ceae0d" class=3D"OWAAutoLink" data-aut= h=3D"NotApplicable">https://eur03.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Flists.seas.upenn.edu%2Fmailman%2Flistinfo%2Funison-hackers&= ;data=3D05%7C02%7Cd.eracledes%40albourne.com%7C2fedefbeb479458cdb7008dd392d= edc3%7C9d1f0723d7114aabb0a87780c86185f2%7C0%7C0%7C638729591620257026%7CUnkn= own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM= iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4000%7C%7C%7C&sdata=3D6f419iu2bUI= OtcsVwZe4JtjXRwAypAzYz0iJx25yl0s%3D&reserved=3D0</a></div> </body> </html> --_000_DB9PR09MB68117D82472646E7A75D3A2D9DE72DB9PR09MB6811eurp_-- --===============0768528289999987431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Unison-hackers mailing list [email protected] https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers --===============0768528289999987431==--