Re: On making times=true the default

--===============1916477098500549618==
Content-Type: multipart/alternative; boundary="000000000000d7129f062c3eaeec"

--000000000000d7129f062c3eaeec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Going back a couple of steps in the conversation, I wanted to say that I am
pretty convinced by the argument that silently propagating the older
modtime in cases of conflict is a reasonable plan (as long as the replica
contents except for modtimes are completely synced beforehand).

I still have a couple caveats:

* There may be corner cases where *only* the modtime of a file has changed,
but not the contents (e.g., the file is always empty and whoever is using
it cares only about the modtime).  In such cases, choosing the older
modtime would be wrong.  But maybe this is such a corner case that it
doesn't really exist.

* I am still a bit uncomfortable about propagating a lot of changes without
explicit agreement / instruction from the user.  It might be worth
introducing a switch that says "Really propagate older modtimes", that
could be used just once when upgrading from the old to the new default
settings.

Best,

     - Benjamin

On Tue, Jan 21, 2025 at 3:53=E2=80=AFPM T=C3=B5ivo Leedj=C3=A4rv <toivol@gm=
ail.com> wrote:

> On Mon, 20 Jan 2025 at 19:05, Greg Troxel <[email protected]> wrote:
> >
> > We could ask:
> >
> >   is our handling of -fat appropriate for -exfat?  (probably not)
> >
> >   is exFAT common enough, and are there standard accomodations, that we
> >   should have an -exfat flag?
> >
> > along with asking if -fat is still needed, as opposed to different
> > people wanting different flags.
>
> I suggest not involving -fat in the current discussion at all. -fat
> does not mean FAT and FAT does not imply -fat. See
>
> https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/6=
38*issuecomment-1044420789__;Iw!!IBzWLUs!Ri0BLkeJ59eMDoBs5SrCfNd2TQklNcPN3e=
tVKfJLlzBlT4ysHIjHCEnHpS8-GuRudixOoGcVizJv_JlduESJ6nYCXe0$
> _______________________________________________
> Unison-hackers mailing list
> [email protected]
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>

--000000000000d7129f062c3eaeec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Going back a couple=C2=A0of=C2=A0steps in the conversation=
, I wanted to say that I am pretty convinced by the argument that silently =
propagating the older modtime in cases of conflict is a reasonable=C2=A0pla=
n (as long as the replica contents except for modtimes are completely=C2=A0=
synced beforehand).<div><br><div>I still have a couple caveats:<div><br></d=
iv><div>* There may be corner cases where *only* the modtime of a file has =
changed, but not the contents (e.g., the file is always empty and whoever i=
s using it cares only about the modtime).=C2=A0 In such cases, choosing the=
 older modtime would be wrong.=C2=A0 But maybe this is such a corner case t=
hat it doesn&#39;t really exist.</div></div></div><div><br></div><div>* I a=
m still a bit uncomfortable about propagating a lot of changes without expl=
icit agreement / instruction from the user.=C2=A0 It might be worth introdu=
cing a switch that says &quot;Really propagate older modtimes&quot;, that c=
ould be used just once when upgrading from the old to the new default setti=
ngs.</div><div><br></div><div>Best,</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0- Benjamin</div></div><br><div class=3D"gmail_quote gmail_quote_conta=
iner"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 21, 2025 at 3:53=E2=
=80=AFPM T=C3=B5ivo Leedj=C3=A4rv &lt;<a href=3D"mailto:[email protected]">t=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex">On Mon, 20 Jan 202=
5 at 19:05, Greg Troxel &lt;<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; We could ask:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0is our handling of -fat appropriate for -exfat?=C2=A0 (pro=
bably not)<br>
&gt;<br>
&gt;=C2=A0 =C2=A0is exFAT common enough, and are there standard accomodatio=
ns, that we<br>
&gt;=C2=A0 =C2=A0should have an -exfat flag?<br>
&gt;<br>
&gt; along with asking if -fat is still needed, as opposed to different<br>
&gt; people wanting different flags.<br>
<br>
I suggest not involving -fat in the current discussion at all. -fat<br>
does not mean FAT and FAT does not imply -fat. See<br>
<a href=3D"https://urldefense.com/v3/__https://github.com/bcpierce00/unison=
/issues/638*issuecomment-1044420789__;Iw!!IBzWLUs!Ri0BLkeJ59eMDoBs5SrCfNd2T=
QklNcPN3etVKfJLlzBlT4ysHIjHCEnHpS8-GuRudixOoGcVizJv_JlduESJ6nYCXe0$" rel=3D=
"noreferrer" target=3D"_blank">https://urldefense.com/v3/__https://github.c=
om/bcpierce00/unison/issues/638*issuecomment-1044420789__;Iw!!IBzWLUs!Ri0BL=
keJ59eMDoBs5SrCfNd2TQklNcPN3etVKfJLlzBlT4ysHIjHCEnHpS8-GuRudixOoGcVizJv_Jld=
uESJ6nYCXe0$</a> <br>
_______________________________________________<br>
Unison-hackers mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Un=
[email protected]</a><br>
<a href=3D"https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers" re=
l=3D"noreferrer" target=3D"_blank">https://LISTS.SEAS.UPENN.EDU/mailman/lis=
tinfo/unison-hackers</a><br>
</blockquote></div>

--000000000000d7129f062c3eaeec--

--===============1916477098500549618==
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

--===============1916477098500549618==--