Re: On making times=true the default
Benjamin Pierce <[email protected]> Thu, 16 Jan 2025 12:14:55 -0500
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <CABgF7-M6VheO+j8No5SzTPgEgmby1fU8P76aAtTypgOYvKu-ig@mail.gmail.com> |
--===============4916025338810979698== Content-Type: multipart/alternative; boundary="000000000000f77b8d062bd5f055" --000000000000f77b8d062bd5f055 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I'm a little nervous about changing defaults on something so fundamental. E.g., we can be careful not to do it when using old archives where times have not been synced, but what if those archives get blown away and the user expects to be able to just run unison again to recreate them from scratch? This is something some people might be quite surprised by. I wonder if there is a less intrusive way. E.g., what about adding a new preference -notimesnowarn, default false, and printing a warning if -times and -reallynotimes are both false, along the lines of "We notice you have -times set to false; we recommend setting it to true, but if you have a good reason for keeping it false, you can suppress this warning by setting -notimesnowarn to true"? On Thu, Jan 16, 2025 at 8:43=E2=80=AFAM Greg Troxel <[email protected]> wrote: > T=C3=B5ivo Leedj=C3=A4rv <[email protected]> writes: > > > TL;DR I'd like to get your opinions and ideas on two questions: 1) Do > > you think times=3Dtrue should be the default? 2) If yes, any suggestion= s > > on how to manage existing users? > > I lean to making it default. I realize this is preference, but I use > 'rsync -av', and I expect unison to be like that. Another view is that > unison replicas are kind of like a distributed filesystem, and mtimes > are simply part of that. > > > I think the main counter-arguments have been two-fold: > > > > 1) FAT filesystems may cause trouble. How real is this issue? Would > > there be trouble (if at all) only at DST changes or any time? > > > I don't know how serious the issue with FAT filesystems is, but is it > > sufficient to dictate a default preference for everyone? Likely not. > > 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". But I don't want to > mess up people that mitigate FAT's time bugs by setting their machines > to UTC. I also don't really want to add kludges for it, at least not > kludges that would affect anybody not asking for FAT kludges. > > I don't think it's reasonable to have people with non-deficient > filesystems default off because of a deficient filesystem. > > > 2) Existing users would get a nasty surprise as potentially their > > entire replicas would be listed as conflicts due to different > > mtimes. > > > As for managing the change for existing users, I'm thinking the solutio= n > > might be to earmark all the archives that are created after this change > > of default. Then, when loading archives without this mark, and the user > > hasn't specified the times preference, we'd set times=3Dfalse again. Th= is > > way, all the new users will get the new default, all the existing users > > will not get a nasty surprise, and all users explicitly setting the tim= es > > preference won't be affected either way. > > That's interesting, but I wonder if this can be easier for people. > > I would say that often there are existing copies of files, intended to > be mostly the same. This could be replicas previously synced by unison > with archive state, by rsync, or by unison but the archive state has > been lost. In all these cases, the mtimes (on files) *ought* to be the > same, and it's more or less a bug if they aren't. > > 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=3Dyes having automatic/silent conflict > resolution where the newer timestamp is set to the older one, as fixing > up past errors. > > 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=3Dno, > times=3Dyes (no auto-conflict-fi), and times=3Dauto (sync, and auto-resol= ve > to older). > > I'm not sure how difficult this is to deal with. I'm just thinking in > terms of what would be nice. > > > Finally, will this new default cause too much confusion? While I think > > it would be the correct default, and should work well for hopefully > > most users, it comes with a risk of confusing and frustrating users in > > some specific situations. > > With auto conflict, I don't think it's trouble. It is possible someone > is relying on copies having newer mtimes, but we can simply ask on users > and hearing nothing, just have it in NEWS. I don't want to pull the rug > out from under people, but if we ask and hear nothing, that's as much as > can reasonably be done. > > > Whenever a user starts syncing two new already-populated replicas, or > > re-creates some existing archives (either by choice or by having lost > > their archives), they may still get a ton of conflicts. This, I hope, > > is acceptable because they can then explicitly set times=3Dfalse if the= y > > wish. When creating new archives and noticing many props conflicts, > > Unison could even display a message hinting the user about this > > preference. > > Yes, but I think this calls for auto-resolve to oldest. > _______________________________________________ > Unison-hackers mailing list > [email protected] > https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers > --000000000000f77b8d062bd5f055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">FWIW, I'm a little=C2=A0nervous about changing default= s on something so fundamental. =C2=A0<div><br></div><div>E.g., we can be ca= reful not to do it when using old archives where times have not been synced= , but what if those archives get blown away and the user expects to be able= to just run unison again to recreate them from scratch?=C2=A0 This is some= thing some people=C2=A0might be quite surprised by. =C2=A0</div><div><br></= div><div>I wonder=C2=A0if there is a less intrusive way.=C2=A0 E.g., what a= bout adding a new preference -notimesnowarn, default false, and printing a = warning if -times and -reallynotimes are both false, along the lines of &qu= ot;We=C2=A0notice you have -times set to false; we recommend setting it to = true, but if you have a good reason for keeping it false, you can suppress = this warning by setting -notimesnowarn to true"?</div></div><br><div c= lass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_= attr">On Thu, Jan 16, 2025 at 8:43=E2=80=AFAM Greg Troxel <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:<br></div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;= border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex= ">T=C3=B5ivo Leedj=C3=A4rv <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> writes:<br> <br> > TL;DR I'd like to get your opinions and ideas on two questions: 1)= Do<br> > you think times=3Dtrue should be the default? 2) If yes, any suggestio= ns<br> > on how to manage existing users?<br> <br> I lean to making it default.=C2=A0 I realize this is preference, but I use<= br> 'rsync -av', and I expect unison to be like that.=C2=A0 Another vie= w is that<br> unison replicas are kind of like a distributed filesystem, and mtimes<br> are simply part of that.<br> <br> > I think the main counter-arguments have been two-fold:<br> ><br> >=C2=A0 =C2=A01) FAT filesystems may cause trouble. How real is this iss= ue? Would<br> >=C2=A0 =C2=A0 =C2=A0 there be trouble (if at all) only at DST changes o= r any time?<br> <br> > I don't know how serious the issue with FAT filesystems is, but is= it<br> > sufficient to dictate a default preference for everyone? Likely not.<b= r> <br> My view is that FAT is a special case, and that FAT has time problems in<br= > general.=C2=A0 It would make sense for people using them to set times off,<= br> maybe, and perhaps that could be part of "-fat".=C2=A0 But I don&= #39;t want to<br> mess up people that mitigate FAT's time bugs by setting their machines<= br> to UTC.=C2=A0 I also don't really want to add kludges for it, at least = not<br> kludges that would affect anybody not asking for FAT kludges.<br> <br> I don't think it's reasonable to have people with non-deficient<br> filesystems default off because of a deficient filesystem.<br> <br> >=C2=A0 =C2=A02) Existing users would get a nasty surprise as potentiall= y their<br> >=C2=A0 =C2=A0 =C2=A0 entire replicas would be listed as conflicts due t= o different<br> >=C2=A0 =C2=A0 =C2=A0 mtimes.<br> <br> > As for managing the change for existing users, I'm thinking the so= lution<br> > might be to earmark all the archives that are created after this chang= e<br> > of default. Then, when loading archives without this mark, and the use= r<br> > hasn't specified the times preference, we'd set times=3Dfalse = again. This<br> > way, all the new users will get the new default, all the existing user= s<br> > will not get a nasty surprise, and all users explicitly setting the ti= mes<br> > preference won't be affected either way.<br> <br> That's interesting, but I wonder if this can be easier for people.<br> <br> I would say that often there are existing copies of files, intended to<br> be mostly the same.=C2=A0 This could be replicas previously synced by uniso= n<br> with archive state, by rsync, or by unison but the archive state has<br> been lost.=C2=A0 In all these cases, the mtimes (on files) *ought* to be th= e<br> same, and it's more or less a bug if they aren't.<br> <br> The nature of syncing, by mechanisms that don't sync times, is that the= <br> source as the old/original mtime, and the destination has a new mtime<br> (at time of sync).<br> <br> So, I would be in favor of times=3Dyes having automatic/silent conflict<br> resolution where the newer timestamp is set to the older one, as fixing<br> up past errors.<br> <br> I can conceive that someone wouldn't want this, even though I am not<br= > sure any actual people don't want it.=C2=A0 So we could have times=3Dno= ,<br> times=3Dyes (no auto-conflict-fi), and times=3Dauto (sync, and auto-resolve= <br> to older).<br> <br> I'm not sure how difficult this is to deal with.=C2=A0 I'm just thi= nking in<br> terms of what would be nice.<br> <br> > Finally, will this new default cause too much confusion? While I think= <br> > it would be the correct default, and should work well for hopefully<br= > > most users, it comes with a risk of confusing and frustrating users in= <br> > some specific situations.<br> <br> With auto conflict, I don't think it's trouble.=C2=A0 It is possibl= e someone<br> is relying on copies having newer mtimes, but we can simply ask on users<br= > and hearing nothing, just have it in NEWS.=C2=A0 I don't want to pull t= he rug<br> out from under people, but if we ask and hear nothing, that's as much a= s<br> can reasonably be done.<br> <br> > Whenever a user starts syncing two new already-populated replicas, or<= br> > re-creates some existing archives (either by choice or by having lost<= br> > their archives), they may still get a ton of conflicts. This, I hope,<= br> > is acceptable because they can then explicitly set times=3Dfalse if th= ey<br> > wish. When creating new archives and noticing many props conflicts,<br= > > Unison could even display a message hinting the user about this<br> > preference.<br> <br> Yes, but I think this calls for auto-resolve to oldest.<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> --000000000000f77b8d062bd5f055-- --===============4916025338810979698== 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 --===============4916025338810979698==--