[Mono-dev] FAMWatcher race condition patch

[Thong Nguyen]

The FAM based FileSystemWatcher has problems monitoring directories
recursively because FAM doesn't support this natively.

FMAWatcher gets around this by telling FAM to monitor a subdirectory every
time a sub directory is created.  This will work but there is a race
condition that occurs when a sub directory is created and populated with
files before FAM is told to monitor the new sub directory.  This results in
files being created without the FSW raising the appropriate events.


For example:

If I'm monitoring the current dir and I do this:

mkdir a; touch a/pok

FAMWatcher should generated a "created a" and a "created pok" event but
actually only generates a "created a" event because the file pok is created
before FAM is told to monitor the ./a directory.  If I put a "sleep 1" pause
between the mkdir and the touch commands FAMWatcher generates the "created
pok" event ok.

The attached patch will help with this situation scanning and raising a
created event for each file or directory discovered in a newly created sub
directory *after* fam is told to monitor it this new sub directory but
before fam events for the new sub directory are dispatched.

The patch isn't perfect.  In some extreme cases, a duplicate created event
may be raised.  The duplicate event would theoretically only occur if the
file is created after FAM is told to monitor the new sub directory but
before the manual scan for the directory (usually a very short amount of
time).  The duplicate event is not ideal but is IMO, much better than
silently missing an event altogether and compared to the race bug in the
example, is a race bug that is very, very unlikely to occur and is not very
detrimental when it occurs.  Most applications will handle the duplicate
created event fine if and when it occurs.

By doing some logging and checking time stamps the duplicate event could be
eliminated but that would require doing a stat() etc on the file/dir and I'm
not sure if the performance hit is worth it...what do people think?

Regards,

^Tum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fam.patch
Type: application/octet-stream
Size: 3010 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060409/b332698b/attachment.obj