What is the role of InternalBuffer in .net FileWatcher

By doing some google,开发者_StackOverflow中文版 i came to know that 'it is used to keep track of file system actions'. But i don't undrstand it's utility, the watcher can directly trigger the event(s) without storing it in some intermediate buffer!!

Is it there to convert asynchronous flow of events (copying/modifying files) into synchrounous event calls ? Also, I am not sure if FileWatcher triggers the events asynchronously.

Can someone please throw some light on this?

You're missing the point of the buffer in your question, I think.

From MSDN, FileSystemWatcher (emphasis mine):

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.

So it's not a buffer of events that it hasn't told you about yet, it's the buffer it offers for windows to support the notifications in the first place, without having to poll. If Windows throws a huge pile of operations at this instance this buffer will overflow and you, the consumer/user of the FileSystemWatcher, will lose some notifications.

The underlying Windows API that makes FileSystemWatcher work is ReadDirectoryChangesW(). Note the 2nd argument, lpBuffer. That's a one-to-one match with the internal buffer whose size you can set with the InternalBufferSize property.

A buffer is required because Windows cannot easily run user code in response to directory changes. These changes are detected by the respective file system drivers, they run in kernel mode. Running user mode code requires an expensive mode switch and a thread context switch, much too expensive to do so for each individual detected change. The buffer is there to collect changes, waiting for the user mode code to start running and empty the buffer.

There's a well documented failure mode for FSW, there could be too many changes to keep up with. You'd see the Error event in managed code. Increasing the buffer size can help, a lot, the default buffer is rather small at 4096 bytes. Making it arbitrary large is not a good idea though, buffer space is also required in the kernel and that's taken from the kernel memory pool. That's a limited resource, gobbling large amounts from the pool affects all programs running on the machine.

The filewatcher will have to buffer request when it can't all handle them at once, which is mainly caused by the code you wrote to react to the events the FileSystemwatcher throws. As far as I know the FileSystemWatcher Events are not asynchonosly but you could spawn thread in an event to make the handling of your codee be asynchronosly. Of course the file system can change multiple files in one go, like delete all files or think of copy paste.

I hope that was clear.

Yes, FileSystemWatcher is used to keep track of changes in the file system. It watches a directory and reports the following changes to any files in the directory:

• OnCreated: Called when a file or directory is created
• OnChanged: Called when a file or directory is changed
• OnRenamed: Called when a file or directory is renamed
• OnDeleted: Called when a file or directory is deleted

The "internal buffer" is how the operating system sends information to the FileSystemWatcher. Its size is controlled by the "InternalBufferSize" property.

If too many changes occur at once the internal buffer can fill up. Then instead of getting all the individual changes you get a single change notification:

• OnError: Called when individual changes were lost because of a buffer overflow

FileSystemWatcher does trigger events asynchronously. Specifically, the event is triggered whenever the file changes.