[Unison-hackers] unison and inotify principle

[Benjamin Pierce]

P.S.  In case you want to help move this bit of design forward, I  
wanted to mention that version 2.28 of Unison actually includes a  
very simple version of this functionality.  Here is the commit log  
entry...

     - Benjamin


* Very preliminary support for triggering Unison from an external
   filesystem-watching utility.  The current implementation is very
   simple, not efficient, and almost completely untested.  Not ready
   for real users.  But if someone wants to help me improve it (e.g.,
   by writing a filesystem watcher for your favorite OS), please let
   me know.

   On the Unison side, the new behavior is incredibly simple:
     - use the text UI
     - start Unison with the command-line flag "-repeat FOO",
       where FOO is name of a file where Unison should look
       for notifications of changes
     - when it starts up, Unison will read the whole contents
       of this file (on both hosts), which should be a
       newline-separated list of paths (relative to the root
       of the synchronization) and synchronize just these paths,
       as if it had been started with the "-path=xxx" option for
       each one of them
     - when it finishes, it will sleep for a few seconds and then
       examine the watchfile again; if anything has been added, it
       will read the new paths, synchronize them, and go back to
       sleep
     - that's it!

   To use this to drive Unison "incrementally," just start it in
   this mode and start up a tool (on each host) to watch for
   new changes to the filesystem and append the appropriate paths
   to the watchfile.  Hopefully such tools should not be too hard
   to write.

   Since I'm an OSX user, I'm particularly interested in writing a
   watcher tool for this platform.  If anybody knows about
   programming against the Spotlight API and can give me a hand,
   that would be much appreciated.


On Jun 3, 2008, at 7:55 AM, Benjamin Pierce wrote:
> Hi Patrice,
>
> This capability is something that I've wanted to add for a long time,
> and I agree with the basics of your design.  But the devil is in the
> details.  For example, exactly what should be the protocol between
> Unison and the external "filesystem watcher" facility?  (I've only
> looked at the OSX one in any detail, but it is not completely
> straightforward to use; for example, it can occasionally get
> overwhelmed and miss updates, and Unison will need to recognize this
> case and react appropriately.  Etc.)  How should the user interface
> behave?  If Unison becomes a completely "background process," how can
> it notify users of conflicts?  And so on.  There are certainly ways
> of addressing all these issues, but it adds up to a nontrivial design
> exercise.
>
> Best,
>
>     - Benjamin
>
>
> On Jun 1, 2008, at 7:20 PM, Patrice Espié wrote:
>> Hi All,
>>
>> I'm new to this mailling list, so I hope not to do too many
>> mistakes ...
>>
>> I'm using unison from a few months now, and my configuration is a
>> bit wide in a geographic point of view : I'm synchronizing (in the
>> two ways) two computers (Linux) between France and China. In
>> France, there is one laptop connected which is locally
>> synchronised ; same situation in China.
>> I get more than 40.000 files, and about 50 Go.
>> I need to sync very often because of internal needs.
>>
>> I can tell you that a huge amount of time is necessary to do the
>> job ... hopefully unison work well.
>>
>> I wonder if unison could be improved in this way : using inotify
>> interface (wich exist on Windows too). In many cases, it could
>> improve the sync process. Perhaps even in all cases where "almost
>> real time" sync is required.
>> I'm not sure that this kind of evolution is quite complex:
>> unison should run in a repeat mode
>> it could check for local modifications (using inotify or so) and
>> buffer file names to be sync'ed
>> an important think : the remote unison should also run in a repeat
>> mode to check it's own side
>> after a (parameterized) delay (say, one minute ?), the sync could
>> occurs on the buffered names
>> Yes, the more complex problem should be : unison must work on both
>> sides (I don't know if it is the case for now in repeat mode).
>> Do you think this is a possible evolution of unison ? I'm a (c+
>> +,java) programmer, and now my job has changer (I'm not in IT part
>> from e few year) but, I can give some help if needed.
>>
>> Any suggestion ?
>> Thanks
>> -- 
>> Patrice Espie
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>