[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