<div dir="auto">Hold on guys.  I still need to go through the new information here and apply it.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023, 2:07 AM Tõivo Leedjärv <<a href="mailto:toivol@gmail.com">toivol@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 15 Oct 2023 at 20:19, Josh Marshall<br>
<<a href="mailto:joshua.r.marshall.1991@gmail.com" target="_blank" rel="noreferrer">joshua.r.marshall.1991@gmail.com</a>> wrote:<br>
><br>
> I'll try your configuration suggestion for making a hand-rolled<br>
> daemon, but I may also look into watchman as well.<br>
<br>
You don't need watchman. Unless you have problems with the built-in<br>
watch mode, in which case you should report bugs.<br>
<br>
All you need to do is: unison -repeat watch<br>
(or add repeat = watch in the profile file if you use profiles)<br>
If you want it to be more like a daemon: nohup unison -repeat watch > /dev/null<br>
In either case, you should see what is going on by looking at the log<br>
file .unison/unison.log (can be overridden by the "logfile"<br>
preference).<br>
<br>
> For atomic file actions, I was thinking of something like<br>
> <a href="https://urldefense.com/v3/__https://linux.die.net/man/1/flock__;!!IBzWLUs!UxgyypTxKgBDlFZfkDT57Le9rH97d2NuA5SjdsvIXtRjYO07_HGdTvqPhkFyeushX9X7Gk5Ybn5uzkirAxM4pOXlpEnm3TXF-fcXQE_p$" rel="noreferrer noreferrer" target="_blank">https://linux.die.net/man/1/flock</a> to lock all files to the acting<br>
> process.  The reason for this being that if there is an interruption<br>
> of some sort which prevents a clean change, then it could be safely<br>
> re-attempted and prevent use by the system where the target file is<br>
> from using the target file.<br>
<br>
Unison does not use flock directly because it doesn't need to, but you<br>
should know that integrity and correctness are its highest priorities.<br>
Unison uses a sort of two step commit transaction method that is<br>
resilient to failures (as much as is possible without the underlying<br>
OS providing actual transactions). This is done for each update, not<br>
for a combination of updates (the "foo and bar" example given by<br>
Greg). Even for the "foo and bar" example there is a workaround: see<br>
the "atomic" preference. (I've never used "atomic" myself, so can't<br>
comment on it.)<br>
<br>
Have you had actual problems with non-clean sync?<br>
<br>
> > The repeat mode can tolerate some failures, such as connection to the server dropping.<br>
> Is this something worth poking at to improve?<br>
<br>
You may have misunderstood me. I meant that it is resilient and fault<br>
tolerant. If it isn't then you should report bugs.<br>
<br>
> > I think that right now ssh:/ as a root hardcodes "ssh", and there is It is not hardcoded. See the "sshcmd" preference.<br>
> I'll take a look.<br>
<br>
You don't need to use mosh either. The scenario you have in mind<br>
should work just fine with plain ol' ssh. If it doesn't, you should<br>
report bugs.<br>
</blockquote></div>