[Unison-hackers] Fwd: Daemonizing Unison and why this is easier said than done

[Josh Marshall]

Good to know that about the fsmonitor feature.  Adding everything to
the README isn't what I was getting at.  A few bullet points as you
suggest would be sufficient.  I might be able to commit for 803.  Is
there a current up to date guidelines for me submitting a patch, or
should we figure that out if/when it materializes?

I'll try your configuration suggestion for making a hand-rolled
daemon, but I may also look into watchman as well.

For atomic file actions, I was thinking of something like
https://urldefense.com/v3/__https://linux.die.net/man/1/flock__;!!IBzWLUs!VTfB3kjB7EG3Wzgxfbq_e4Fx_TllBzPKlsE3ZgaNC9ZU8daI99LzfMxB9mNmrzaFskyBshhZxFwnRItPs-DQggatIlaD14m3F85wdVEa$  to lock all files to the acting
process.  The reason for this being that if there is an interruption
of some sort which prevents a clean change, then it could be safely
re-attempted and prevent use by the system where the target file is
from using the target file.

> The repeat mode can tolerate some failures, such as connection to the server dropping.
Is this something worth poking at to improve?

> I think that right now ssh:/ as a root hardcodes "ssh", and there is It is not hardcoded. See the "sshcmd" preference.
I'll take a look.

Thanks, all!

On Sun, Oct 15, 2023 at 3:43 AM Tõivo Leedjärv <toivol at gmail.com> wrote:
>
> On Sat, 14 Oct 2023 at 02:36, Greg Troxel <gdt at lexort.com> wrote:
> >
> > I think that right now ssh:/ as a root hardcodes "ssh", and there is
>
> It is not hardcoded. See the "sshcmd" preference.