By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,617 Members | 1,166 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,617 IT Pros & Developers. It's quick & easy.

FileSystemWatcher is unreliable

P: n/a
We have noticed that the FileSystemWatcher is not reliable. It is not easily
repeatable but sometime it fails to catch file system changes. When it gets
into this state it doesn't recover unless a reboot is done.

The problem is only seen when multiple files are copied to the system in
quick succession. Once the watcher misses a file *any* subsequent incoming
file isn't seen.

I found this comment on the http://www.experts-exchange.com site:

I also include a "directory sweep" that periodically checks the directories
that the filewatchers are monitoring to make certain no files have been
missed and to detect files that may have been created while the filewatchers
were not running. remember if a file is placed in a directory and the file
watcher is started afterwords - the File_Created event will not fire.

It seems that others have experienced this bugger.

Any other ideas or comments?

-jeff
Feb 23 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
> We have noticed that the FileSystemWatcher is not reliable.

I think FileSystemWatcher is implemented using win32 api
ReadDirectoryChangesW. If that is true, then the documented limitations of
ReadDirectoryChangesW will convey to FileSystemWatcher. One such limitation
is associated with many updates in a short period of time.

If all of the above is true (sorry, I really don't know), then a belt and
suspenders design is to use a timer to trigger an examination everything in
the directory of interest, in other words, polling, and you could be smart
about the polling interval. During periods of heavy file activity, decrease
the interval. During periods of file inactivity, increase the interval. A
FileSystemWatcher could set the interval to 'immediate' when it sees
something. In this way, you would process quickly when the watcher sees
something, but you will always get around to it if the watcher fails.

In this kind of design, I would use the FileSystemWatcher only as a trigger
to look at all files - I would not use it to trigger specific files. I think
if you limit the watcher to trigger only, its reliability will improve. And
you could periodically reinstantiate the watcher object. If you really have
a failure mode that requires a reboot, then I wouldn't use it at all, but my
guess is that reinstantiating it fixes whatever failures you may be
encountering.

In programming, as in boxing, protect yourself at all times. Good luck.
Feb 24 '06 #2

P: n/a
Arnie wrote:
We have noticed that the FileSystemWatcher is not reliable. It is not easily
repeatable but sometime it fails to catch file system changes. When it gets
into this state it doesn't recover unless a reboot is done.

The problem is only seen when multiple files are copied to the system in
quick succession. Once the watcher misses a file *any* subsequent incoming
file isn't seen.

I found this comment on the http://www.experts-exchange.com site:

I also include a "directory sweep" that periodically checks the directories
that the filewatchers are monitoring to make certain no files have been
missed and to detect files that may have been created while the filewatchers
were not running. remember if a file is placed in a directory and the file
watcher is started afterwords - the File_Created event will not fire.

It seems that others have experienced this bugger.

Any other ideas or comments?


I wrote a service that monitored an "inbox" folder and, when a file write
occured, moved the file to a work folder for processing. After processing, it
handles the next write that might have occured, and so on.

The watcher event triggered the moment the write began, meaning that my process
had to wait until the file finished. While the thread was waiting, I might have
several more files arrive; if I wait too long, the events timeout from the queue
and the files are not processed, leaving orphaned files that weren't processed.
I tried multi-threading, but that introduced other problems (such as a shared
printer object) that I was unable to solve to my satisfaction.

In the end, I threw away the FileSystemWatcher and recreated the previous, non
..NET method I used successfully for several years: sleep the main thread for a
minute, have it process up to five files from the inbox, sleep for 60 seconds,
repeat.
--
Gregory Gadow
Feb 24 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.