[Unison-hackers] temp file prefix/suffix

[Benjamin Pierce]

I'm fine with the current way, but also see no problem with this proposal.

   - Benjamin

On Sat, Sep 6, 2025 at 10:19 AM Greg Troxel <gdt at lexort.com> 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-swgA8bRAdLT4aK5RJPZL28x3Y4z5Fd2NC0BhNHUbmSrLigBmuGex50VUiu$
>
>
> Right now we have in src/os.ml:
>
>   let tempFilePrefix = ".unison."
>   let tempFileSuffixFixed = ".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
> Unison-hackers at LISTS.SEAS.UPENN.EDU
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20250906/55a5650e/attachment.htm>