多个 FileSystemWatchers 来监视本地系统上的文件？
我们正在为我们的内部会计包系统编写一个类似于文本编辑器的工具，它具有可以通过我们自己的 Xml 语言规范来完成的操作。这些宏命令在 Xml 文件中指定，我们需要能够监视打开的文件是否已被外部修改。
唯一的问题是，可能同时打开 20-30 个具有不同路径的文件。对于这种情况，使用多个 FileSystemWatcher 会好吗？或者监视根驱动器并捕获与编辑器中打开的文件匹配的特定事件会更好（尽管可能会引发很多事件）。
有些是本地驱动器（C、D、E），其他是网络驱动器（U、X、G、H）。文件也很大，大约 300-400Kb。
We're writing a text editor like tool for our internal accounting package system that has actions that can be done by our own Xml language specs. These macro commands are specified in Xml files and we need the ability to monitor if files openned have bean modified externally.
The only problem is that there maybe 20-30 files with different paths openned at any one time. Would it be good to use multiple FileSystemWatchers for this scenario? Or would it be better to monitor the root drive and catch specific events that match an open file in the editor (though lots of events could be raised).
Some are local drives (C,D,E) others are their network drives (U,X,G,H). Files are quite chunky too about 300-400Kb.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先一些事实
1- FileSystemWatcher 是 ReadDirectoryChanges 的包装器
2- ReadDirectoryChanges 为每次调用 ReadDirectoryChanges 创建一个内核缓冲区来缓存非分页池内存中的事件
上面第 2 点的含义是 FileSystemWatcher 的每个实例都将从非分页池分配内存。请记住，这是用于内核模式驱动程序等的内存，虽然它可以动态扩展，但它“硬”限制在启动时根据系统资源计算的最大大小（机器有多少内存） ）。
因此，考虑到上述情况，我会考虑以下内容。
如果您期望看到的变化量。如果这个值很低，请选择具有最小缓冲区大小的多个观察程序。
如果您决定使用大缓冲区，还请记住，监视网络驱动器不支持超过 64K 的缓冲区大小，甚至更大并且您将不会收到事件。
First a few facts
1- FileSystemWatcher is a wrapper around ReadDirectoryChanges
2- ReadDirectoryChanges creates a kernal buffer to cache event from the non-paged pool memory for each call to ReadDirectoryChanges
The implication of point 2 above is that each instance of FileSystemWatcher will allocate memory from the non-paged pool. Keep in mind that this is the memory used for kernel mode drivers etc. and while it can dynamically expand, it is "hard" limited to a max size calculated at boot time based on the resources of your system (how much memory the machine has).
So given the above, I would consider the following.
If the volume of changes you would expect to see. If this is low, go for multiple watchers with the smallest buffer size you can get away with.
Also keep in mind if you decide to go for big buffers, monitoring network drives does not support buffer sizes over 64K, bigger than that and you will not get the events.
我认为你几乎肯定需要多个观察者。
FileSystemWatcher的缓冲区可能会溢出，您可能会错过事件，否则，您可以更改缓冲区大小（使用InternalBufferSize），但最多只能为 64KB。但是，请注意，
FileSystemWatcher使用FindFirstChangeNotification，这对于网络驱动器来说并不完全可靠（特别是在负载较重的情况下，但也可能在其他情况下），因此您必须预期并计划您不会收到来自网络的每个事件，我的理解是，如果您有多个观察者，可靠性会变得更差。所以总而言之，我认为你必须增加缓冲区，尽可能多地过滤，然后在不溢出缓冲区的情况下使用尽可能少的观察者，所以可能需要进行一些尝试和错误才能得到正确的结果。
I'd think that you'd almost certainly need multiple watchers. The
FileSystemWatchers buffer can overflow and you could miss events otherwise, you can change the buffer size (usingInternalBufferSize) but only up to 64KB.However, be aware that
FileSystemWatcheruseFindFirstChangeNotificationwhich is not totally reliable for networked drives (especially if under heavy load, but possibly otherwise too) so you have to expect and plan for that you won't receive every event from the network, and my understanding is that the reliability gets even worse if you've got multiple watchers.So in summary, I think you'll have to increase the buffers, filter as much as possible and then use as few watchers as you can without overflowing the buffers, so will probably have to be a bit of trial and error to get it right.