[Discuss] Sync Revisited: inotify

[bogstad at pobox.com (Bill Bogstad)]

On Wed, Jul 30, 2014 at 8:07 PM, Edward Ned Harvey (blu)
<blu at nedharvey.com> wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Tom Metro
>>
>> This could be avoided with architectural changes. Specifically using
>> inotify[1] on Linux to monitor a file system. (See also fsnotify[2].) A
>
> This is a partial truth.  The real truth is:  inotify is specific to linux, but every OS has some alternate solution to do the same thing.  Gosh it sucks to write platform specific code to handle every different OS filesystem specifics, but there's the .Net(/mono) FileSystemWatcher class which abstracts all that away and works on ext4/btrfs/fat/ntfs/cifs and probably some more filesystems, but doesn't quite work on HFS+.  This is what we're using in Synctuary, and the end result was we only needed to write platform specific code for the mac.  Everything else was all handled by FileSystemWatcher.
>
> This doesn't alleviate the need to scan the filesystem at startup.  Because filesystem changes could have occurred while your application wasn't running.
>
> But yeah.  After starting the watcher, and scanning the tree once, then you can just follow the events...  Oh wait, there's one more thing.  If changes happen too quickly, then the event queue can overflow which causes you to miss events.  Fortunately it raises an event to notify you that events were lost.  But the only solution is to then scan the whole tree again.  There's nothing you can do to prevent this behavior if the user triggers it, but in Synctuary, we had to write a throttled recursive directory delete method, because the built-in Directory.Delete() method almost always overflows the event queue.

If anyone is interested LWN (Linux Weekly News) had a two part series
on inotify, etc. recently.

http://lwn.net/Articles/605313/

Bill Bogstad