On Wed, Jul 30, 2014 at 8:07 PM, Edward Ned Harvey (blu) <b...@nedharvey.com> wrote: >> From: discuss-bounces+blu=nedharvey....@blu.org [mailto:discuss- >> bounces+blu=nedharvey....@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 _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
