FileSystemWatcher InternalBufferOverflow

当我试图监视网络路径上的文件夹（DFS – 分布式文件系统）时，我收到exceptionSystem.IO.Internal.BufferOverflowException：一次到多个更改。 当FileSystemWatcher监视不使用此文件系统的本地/网络路径时，它可以正常工作。

我能够从本地路径上的1000+文件中获取一个事件，而我没有得到BufferOverflowexception，但是当我将文件复制到DFS上的文件夹时，我甚至无法从一个文件中获取事件（为了澄清这一点，我收到了错误事件…）。

我已经尝试过设置：

fileSystemWatcher.InternalBufferSize = 65536; 

我不确定这对你有帮助，但路径看起来像这样：

 \\corpnet\cloud\\Network\testFolder\myFolderToMonitor 

编辑：1我不知道为什么路径中有两个双斜杠。 我可以监控没有问题的文件夹，直到\ corpnet \ cloud路径。 一旦我尝试监视任何开始的文件夹，我就会收到错误

 ...\\Network\... 

你的任何提示都表示赞赏。

谢谢

Answer 1

当然，一次变化太多，这是一个消防问题。 您已经将缓冲区大小增加到允许的最大值，Windows不允许更大的缓冲区大小。 它被分配在“珍贵”的内存中，即内核内存池。

这可能是一个高度活跃的文件服务器，但更常见的是这是由代码中的问题引起的。 你不要快速地从firehose喝酒。 您的事件处理程序必须尽快返回，以便缓冲区足够快地清空，并且可以跟上文件服务器上的更改速率。

这经常是摸索，一个典型的实现做一些不明智的事情，如复制文件，读取文件，循环直到文件可以打开。 昂贵的东西，循环错误是一个非常常见的错误，当事件触发时，文件很少可用，因为任何更改文件的应用程序仍然打开它。 它可以保持对文件的锁定时间没有上限。 显然，这总会导致缓冲区溢出。

因此，正确实现的FileSystemWatcher事件处理程序除了快速将传递的文件路径放入线程安全的队列中之外什么都不做，并且不执行任何其他操作，从不应该花费超过一微秒。 并使用另一个线程再次尝试清空该队列，处理文件无法打开的可能性。

Answer 2

我遇到了同样的问题。 观看本地文件夹并放入5个新文件没有问题。 但是，当我观看网络文件夹时，我收到错误“目录中的一次更改太多”。 它只有5个文件。

你已经找到了解决办法？

我无法真正调整代码，所以我的临时修复是将文件放在临时文件夹中并轮询该文件夹。 当有新文件时，我将它们分开移动500ms延迟