Re: temp file prefix/suffix
Benjamin Pierce <[email protected]> Sat, 6 Sep 2025 14:37:11 -0400
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <CABgF7-Mh7WKaF0mDmT_f6ePj7d7--ijsMvmrKKDZ8CTe0WoBxw@mail.gmail.com> |
--===============2309901397390356393== Content-Type: multipart/alternative; boundary="0000000000003d5c26063e264016" --0000000000003d5c26063e264016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm fine with the current way, but also see no problem with this proposal. - Benjamin On Sat, Sep 6, 2025 at 10:19=E2=80=AFAM Greg Troxel <[email protected]> wrote: > [This might be a little off, in which case corrections welcome.] > > We have a long-open PR to make these configurable, and as y'all know I > have a bias against configuration, believing that there's a cogntive > burden and a maintenance burden. > > > https://urldefense.com/v3/__https://github.com/bcpierce00/unison/pull/447= __;!!IBzWLUs!WyXHnut9ekKJk_B27vvNSm2PJxIWr-swgA8bRAdLT4aK5RJPZL28x3Y4z5Fd2N= C0BhNHUbmSrLigBmuGex50VUiu$ > > > Right now we have in src/os.ml: > > let tempFilePrefix =3D ".unison." > let tempFileSuffixFixed =3D ".unison.tmp" > > with the idea that a file is unison tmpfile if both are present. > > > As I see it the basic problems are: > > This is layered temp, in that editor temp files end in ~ (on unix), > but you might want to sync those. This is about files that are > extra-temporary, that unison can recognize as its own. So we really > need something unison-specific. > > When using another sync at the same time, one might want to exclude > unison temp files, but not exclude editor temp files. > > conventions vary across OSes > > people may be using remote filesystems. They might be running unison > from multiple computers on the same remote data. They might be using > other sync on the same data. There are lots of possibilities and it > very quickly gets into "don't do that", in my view. > > and cultural background/bias > > pretty much every sync mechanism has configurable exclusion. unison, > rsync, nextcloud all do. It seems dropbox is the one that does not. > So this seems to be a dropbox problem, not a unison problem. > > > > My questions are: > > It might be better to have sborter annotations, as long as there is > liitle risk of collisions. That could help in encrypted filesystems > wiht shorter pathname requirements, etc. Does anyone think I'm off to > prefer shorter, as long as it's long enough? > > On Unix, we have conventions of .foo for "hidden", meaning ls doesn't > show them without -a. But there is no culture of not syncing such > files by default. I'm going to say that hidden and .-prefixed are not > really relevant here, except that it's perhaps nice to make these > tmpfiles not so user-visible. So we choose a .-prefixed name, but > it's for the nicety of ls usage, not functional. Correct thinking? > > On Unix, we have a convention of ~ as backup/tmp, sometimes excluded, > sometimes not. So probably these tmp files should end in ~, so that > a "don't sync *~" will catch them. > - Does that make sense? > - Does that work with dropbox? > > The ~ convention seems to apply on macOS, as it isn't that different. > Correct? > > What's the situation on Windows? (I try hard not to use Windows at > all, as a personal choice.) > > Is there anyone who wants to exclude editor backup files form sync, > but does *not* want to exclude unison temp files? I am assuming there > are no such people and this is something we can totally not support. > > and therefore > > What if we set prefix to ".Utmp." and suffice to ".U~", unconditionally? > > - Does that cause any harm to existing usage? > > - Does it enable excluding these more easily on dropbox? Does it > result in automatic exclusion? > > > Is there some equivalent convention to trailing ~ on Windows, and > could we use it alternatively or simultaneously? I think I saw .~foo > in discussion. > > > And finally: > > Does anyone on the hackers list care about this issue at all? Does > the silent majority think that there is no problem? > > > Thanks, > Greg > _______________________________________________ > Unison-hackers mailing list > [email protected] > https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers=20 > --0000000000003d5c26063e264016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'm=C2=A0fine with the current=C2=A0way, but also see = no problem with this proposal.<div><br></div><div>=C2=A0 =C2=A0- Benjamin</= div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"= ltr" class=3D"gmail_attr">On Sat, Sep 6, 2025 at 10:19=E2=80=AFAM Greg Trox= el <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2= 04);padding-left:1ex">[This might be a little off, in which case correction= s welcome.]<br> <br> We have a long-open PR to make these configurable, and as y'all know I<= br> have a bias against configuration, believing that there's a cogntive<br> burden and a maintenance burden.<br> <br> =C2=A0 <a href=3D"https://urldefense.com/v3/__https://github.com/bcpierce00= /unison/pull/447__;!!IBzWLUs!WyXHnut9ekKJk_B27vvNSm2PJxIWr-swgA8bRAdLT4aK5R= JPZL28x3Y4z5Fd2NC0BhNHUbmSrLigBmuGex50VUiu$" rel=3D"noreferrer" target=3D"_= blank">https://urldefense.com/v3/__https://github.com/bcpierce00/unison/pul= l/447__;!!IBzWLUs!WyXHnut9ekKJk_B27vvNSm2PJxIWr-swgA8bRAdLT4aK5RJPZL28x3Y4z= 5Fd2NC0BhNHUbmSrLigBmuGex50VUiu$</a> <br> <br> <br> Right now we have in src/<a href=3D"https://urldefense.com/v3/__http://os.m= l__;!!IBzWLUs!U2QL7R6NxOV6CMxt-7aJHekIfdNl-DgSqqaXbpE2G8blSB2XiHda-1pxj5eDy= q6dW42iCFyxrqzbMfvddpl4NZ4I0eZVx9-ugjqx$" rel=3D"noreferrer" target=3D"_bla= nk">os.ml</a>:<br> <br> =C2=A0 let tempFilePrefix =3D ".unison."<br> =C2=A0 let tempFileSuffixFixed =3D ".unison.tmp"<br> <br> with the idea that a file is unison tmpfile if both are present.<br> <br> <br> As I see it the basic problems are:<br> <br> =C2=A0 This is layered temp, in that editor temp files end in ~ (on unix),<= br> =C2=A0 but you might want to sync those.=C2=A0 This is about files that are= <br> =C2=A0 extra-temporary, that unison can recognize as its own.=C2=A0 So we r= eally<br> =C2=A0 need something unison-specific.<br> <br> =C2=A0 When using another sync at the same time, one might want to exclude<= br> =C2=A0 unison temp files, but not exclude editor temp files.<br> <br> =C2=A0 conventions vary across OSes<br> <br> =C2=A0 people may be using remote filesystems.=C2=A0 They might be running = unison<br> =C2=A0 from multiple computers on the same remote data.=C2=A0 They might be= using<br> =C2=A0 other sync on the same data.=C2=A0 There are lots of possibilities a= nd it<br> =C2=A0 very quickly gets into "don't do that", in my view.<br> <br> and cultural background/bias<br> <br> =C2=A0 pretty much every sync mechanism has configurable exclusion.=C2=A0 u= nison,<br> =C2=A0 rsync, nextcloud all do.=C2=A0 It seems dropbox is the one that does= not.<br> =C2=A0 So this seems to be a dropbox problem, not a unison problem.<br> <br> <br> <br> My questions are:<br> <br> =C2=A0 It might be better to have sborter annotations, as long as there is<= br> =C2=A0 liitle risk of collisions.=C2=A0 That could help in encrypted filesy= stems<br> =C2=A0 wiht shorter pathname requirements, etc.=C2=A0 Does anyone think I&#= 39;m off to<br> =C2=A0 prefer shorter, as long as it's long enough?<br> <br> =C2=A0 On Unix, we have conventions of .foo for "hidden", meaning= ls doesn't<br> =C2=A0 show them without -a.=C2=A0 But there is no culture of not syncing s= uch<br> =C2=A0 files by default.=C2=A0 I'm going to say that hidden and .-prefi= xed are not<br> =C2=A0 really relevant here, except that it's perhaps nice to make thes= e<br> =C2=A0 tmpfiles not so user-visible.=C2=A0 So we choose a .-prefixed name, = but<br> =C2=A0 it's for the nicety of ls usage, not functional.=C2=A0 Correct t= hinking?<br> <br> =C2=A0 On Unix, we have a convention of ~ as backup/tmp, sometimes excluded= ,<br> =C2=A0 sometimes not.=C2=A0 =C2=A0So probably these tmp files should end in= ~, so that<br> =C2=A0 a "don't sync *~" will catch them.<br> =C2=A0 =C2=A0 - Does that make sense?<br> =C2=A0 =C2=A0 - Does that work with dropbox?<br> <br> =C2=A0 The ~ convention seems to apply on macOS, as it isn't that diffe= rent.<br> =C2=A0 Correct?<br> <br> =C2=A0 What's the situation on Windows?=C2=A0 (I try hard not to use Wi= ndows at<br> =C2=A0 all, as a personal choice.)<br> <br> =C2=A0 Is there anyone who wants to exclude editor backup files form sync,<= br> =C2=A0 but does *not* want to exclude unison temp files?=C2=A0 I am assumin= g there<br> =C2=A0 are no such people and this is something we can totally not support.= <br> <br> and therefore<br> <br> =C2=A0 What if we set prefix to ".Utmp." and suffice to ".U~= ", unconditionally?<br> <br> =C2=A0 =C2=A0 - Does that cause any harm to existing usage?<br> <br> =C2=A0 =C2=A0 - Does it enable excluding these more easily on dropbox?=C2= =A0 Does it<br> =C2=A0 =C2=A0 =C2=A0 result in automatic exclusion?<br> <br> <br> =C2=A0 Is there some equivalent convention to trailing ~ on Windows, and<br> =C2=A0 could we use it alternatively or simultaneously?=C2=A0 I think I saw= .~foo<br> =C2=A0 in discussion.<br> <br> <br> And finally:<br> <br> =C2=A0 Does anyone on the hackers list care about this issue at all?=C2=A0 = Does<br> =C2=A0 the silent majority think that there is no problem?<br> <br> <br> Thanks,<br> Greg<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> --0000000000003d5c26063e264016-- --===============2309901397390356393== 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 --===============2309901397390356393==--