0
Best Practices for FileSystemWatcher
1. Use a shared file queue and only add to the queue in the event handlers
as stated in here: and
to avoid the buffer over-flow limitations and file open limitations.
2. Use two separate FileSystemWatchers to monitor a folder; one for files
and one for folders. You need a separate one for folders, because a move
(cut and paste) operation on a folder will not always generate events for the
individual files within the moved folder but only the renamed event for the
folder name. Thus you will have to call GetFiles() yourself.
3. To minimize duplicate events, do not edit the shared queue but remove
duplicates before adding to the queue with a simple string dictionary of
order; save the last 5 or 10 file names with the TimeStamp and if the same
file name occurs within the last 500 ms than do not add to the queue.
This is all needed because of the following limitations I have come across:
Issues with FileSystemWatcher:
1. Some File / Directory events result in duplicate events being raised.
Example: Edit a file in Notepad and you will get duplicate events. Edit a
file in MS Word and you will get multiple events as it uses a temp file in
that folder (create, change, rename, delete). For example, when a file is
moved from one directory to another, several OnChanged and some OnCreated and
OnDeleted events might be raised. Likewise, some applications (for example,
antivirus software) might cause additional file system events that are
detected by FileSystemWatcher.
2. If my process changes the file, the FSW calls me. How do I know I was
the only one who changed it?
3. Can get buffer over-flow quite easily.
4. Files are not always closed when an event is raised.
5. When moving a watched subfolder within a watched folder the files are not
detected BUT new files are detected if a non-watched folder is moved into a
watched folder.