The FileSytemWatcher component uses an internal buffer to keep track of filesystem actions. By default, the buffer is set to a size of 4 KB. A 4 KB buffer can track changes on approximately 80 files in a directory. Each event takes up 16 bytes in the buffer, plus enough bytes to store the name of the file, in Unicode (two bytes per character), that the event occurred on. You can use this information to approximate the buffer size you will need. You reset the buffer size by setting the InternalBufferSize property.
Why are we talking about this? Because 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 will affect correct notification. Increasing the size of the buffer is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so we must keep the buffer as small as possible. Setting the filter does not decrease what goes into the buffer. If you are using Microsoft Windows 2000, you should increase the buffer size in increments of 4 KB, because this corresponds to the operating system's default page size. With any other operating system, you should increase the buffer size in increments that correspond to the operating system's default page size. If you are unsure of the default page size for the operating system you are using, the safest way to proceed is to just double the original size of the buffer. This will maintain the original interval needed for your operating system.
In this chapter, I will present two solutions for file watching for you. You can choose the style you like most. The first will wrap the Windows FileSystemWatcher object into two unique and helpful classes. The second will be more aggressive in reducing the number of events raised through the system. Why do I mention this?
For those who have worked with the Windows FileSystemWatcher object before, you know that one file action on your part can result in many events being generated. You think there should just be one created event, but, in fact, several Created, Changed, and Renamed events are possible. Something like this you would never expect unless you worked with it. Here's an example of what I mean.
Excel triggers 15 NTFS events for four different files when creating a single new .xlsx file and triggers eight events for three different files, of which none is a changed event for the file change one would naively expect. Just take a look at what is really happening behind the scenes:
