FileSystemWatcher skips Created-events

Question

I have a FileSystemWatcher that checks multiple directories if there are any files created.

            ((System.ComponentModel.ISupportInitialize)(FileMonitor)).BeginInit();
            FileMonitor.EnableRaisingEvents = true;
            FileMonitor.Created += new FileSystemEventHandler(FileMonitor_Created);
            FileMonitor.Path = Path.ToString();
            FileMonitor.IncludeSubdirectories = true;
            FileMonitor.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName | NotifyFilters.Attributes;
            ((System.ComponentModel.ISupportInitialize)(FileMonitor)).EndInit();

For some reason the FileMonitor_Created event is not always fired when running the application, even though it should. It feels random...

However, if I put a breakpoint at the FileMonitor_Created method, it works perfectly: The event fires everytime it should, if the breakpoint is set.

I've tried setting an InterBufferSize for the FileMonitor, but that had no effect.

Update

I added the Changed event to the Filemonitor and gave it the same handler as for the Created event. Somehow it works now, although the file is actually created, not changed.

I'm still curious why it always worked 'the old way' when setting a breakpoint.

Answer 1

How many changes are you making?

The Windows operating system notifies your component of file changes in a buffer created by the FileSystemWatcher. If there are many changes in a short time, the buffer can overflow. This causes the component to lose track of changes in the directory, and it will only provide blanket notification. Increasing the size of the buffer with the InternalBufferSize property is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so keep the buffer as small yet large enough to not miss any file change events. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications.

Taken from MSDN

Answer 2

If you have a breakpoint its working, but if you don't, its not?

Are you sure that there's not something in your event handler? Like there's an exception occurring which makes the program 'feel' like its not doing anything? Can you post the code in the handler?

Answer 3

When event is raised, file processing might take some time. During that time another file might be created and event handler will not handle the second file because it is still handling the first file. Therefore, second file is missed by FileSystemWatcher.

Solution is to separate file detection form file processing into two threads and connect then by a queue. It is producer-consumer queue.

File detection should be as short as can be. It should only detect a file, enqueue its file name in queue that file processing thread can process and close so another file can be detected. File processing thread can dequeue file name and take as much time as it needs to process it.

I explained this in detail with the code in this article: FileSystemWatcher skips some events

Answer 4

Separate your business logic from the FileMonitor_Created event. In the event you should store the event parameters and return. E.g. store the event parameters in a queue, then process these events async.

Answer 5

FileMonitor.Created fires when the file created and not replaced with the previous file with the same created date time.

Scenario 1) Copy paste and over right the same abc.txt File in input folder without any changes to the file creation date or file content- - File watcher doesn't recognize the file.

Scenario 2) Copy paste and over right the same file in input folder with new created date File watcher recognizes the file

So the created event works with the second scenario, it might not be your situation but looks hidden behavior for my first view.