<div dir="auto"><div>I am entirely unfamiliar with fs monitor.  It never came up in my searches or unison documentation.  One easy thing could be to mention fsmonitor in the README.</div><div dir="auto"><br></div><div dir="auto">I do mean as a long running process.  Full fat unambiguous this is a system service and daemon.  Using Mosh over ssh addresses some of the partial action, but so too would atomic file commits.  I still don't think addressing handling multiple users needs to be included yet.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Oct 13, 2023, 6:53 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Josh Marshall <<a href="mailto:joshua.r.marshall.1991@gmail.com" target="_blank" rel="noreferrer">joshua.r.marshall.1991@gmail.com</a>> writes:<br>
<br>
> Having my two computers sync as changes happen seems nice and<br>
> ostensibly easy to implement.  Famous last words, I know.  But why<br>
> would a Unison daemon be difficult to impractical?<br>
<br>
Are you aware of the various fsmonitor implementations?  Leaving unison<br>
running (and the corresponding remote) seems to be routine for many<br>
already.  So I'm not sure which piece you think is missing, and what it<br>
might do instead.  See "-repeat watch" and src/fsmonitor*.<br>
<br>
Certainly the fsmonitor world could be better documented.<br>
<br>
I wonder if you mean support for closing stdin/stdout, using syslog for<br>
logging, controlling terminal dissociation, etc.  This is fairly minor,<br>
and can be achieved with nohup(1) and redirection, plus some futzing<br>
around for logging.  If so, that seems like a reasonable thing to add.<br>
<br>
You also might mean support for long-running processes on both sides<br>
that survive disconnection.  That raises issues about partial processing<br>
while disconnected, vs only doing connected processing and queuing<br>
input.  It also raises issues about ssh and reconnection in terms of<br>
future access to authentication, vs running over D-TLS or some other<br>
schemes.<br>
<br>
You didn't mention this, but unison operates under a single uid, and one<br>
could want synchronization of files belonging to multiple users.  So far<br>
we haven't really crossed that line fully.<br>
<br>
<br>
<br>
</blockquote></div></div></div>