.net FileWatcher中InternalBuffer的作用是什么
通过谷歌搜索，我了解到“它用于跟踪文件系统操作”。但我不明白它的实用性，观察者可以直接触发事件而不将其存储在某些中间缓冲区中！
是否可以将异步事件流（复制/修改文件）转换为同步事件调用？另外，我不确定 FileWatcher 是否异步触发事件。
有人可以解释一下吗？
By doing some google, 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为你错过了问题中缓冲区的要点。
来自MSDN，FileSystemWatcher（重点是我的）：
因此，它不是尚未告诉您的事件缓冲区，而是它为窗口提供的缓冲区，用于首先支持通知，而无需进行轮询。如果 Windows 在这种情况下抛出大量操作，则该缓冲区将溢出，并且您（FileSystemWatcher 的使用者/用户）将丢失一些通知。
You're missing the point of the buffer in your question, I think.
From MSDN, FileSystemWatcher (emphasis mine):
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.
使 FileSystemWatcher 工作的底层 Windows API 是 ReadDirectoryChangesW() 。注意第二个参数 lpBuffer。这是与内部缓冲区的一对一匹配，您可以使用 InternalBufferSize 属性设置其大小。
需要缓冲区是因为 Windows 无法轻松运行用户代码来响应目录更改。这些更改由各自的文件系统驱动程序检测到，它们在内核模式下运行。运行用户模式代码需要昂贵的模式切换和线程上下文切换，对于每个检测到的单独更改来说这样做成本太高。缓冲区用于收集更改，等待用户模式代码开始运行并清空缓冲区。
FSW 有一个详细记录的故障模式，可能有太多的变化需要跟上。您会在托管代码中看到 Error 事件。增加缓冲区大小会有很大帮助，默认缓冲区相当小，为 4096 字节。不过，使其任意大并不是一个好主意，内核中也需要缓冲区空间，并且该空间是从内核内存池中获取的。这是一种有限的资源，从池中吞噬大量资源会影响计算机上运行的所有程序。
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.
当文件观察器无法同时处理所有请求时，它必须缓冲请求，这主要是由您编写的对 FileSystemwatcher 引发的事件做出反应的代码引起的。据我所知，FileSystemWatcher 事件不是异步的，但您可以在事件中生成线程以使代码处理的处理异步。当然，文件系统可以一次性更改多个文件，例如删除所有文件或复制粘贴。
我希望这是清楚的。
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.
是的，FileSystemWatcher 用于跟踪文件系统中的更改。它监视目录并报告目录中任何文件的以下更改：
“内部缓冲区”是操作系统向 FileSystemWatcher 发送信息的方式。其大小由“InternalBufferSize”属性控制。
如果一次发生太多更改，内部缓冲区可能会被填满。然后，您将获得一个更改通知，而不是获取所有单独的更改：
FileSystemWatcher 会异步触发事件。具体来说，只要文件发生更改，就会触发该事件。
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:
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:
FileSystemWatcher does trigger events asynchronously. Specifically, the event is triggered whenever the file changes.