[Unison-hackers] temp file prefix/suffix

Greg Troxel gdt at lexort.com
Sat Sep 6 10:19:47 EDT 2025


[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


More information about the Unison-hackers mailing list