除了具有 320K 子目录的根文件夹之外，FileSystemWatcher 甚至一次都无法工作

如何解决除了具有 320K 子目录的根文件夹之外，FileSystemWatcher 甚至一次都无法工作

我使用下面的代码来监视目录（包括子目录）中发生的更改。目前，我正在运行此应用程序的三个不同副本，其中两个运行良好。它不工作的应用程序包含超过 320K 的子目录。

我试图增加 InternalBufferSize 但没有任何反应。它在根文件夹中工作，不适用于任何子目录。

此外，监控不同地理位置的不同网络路径的同一应用程序的另外 2 个副本也能正常工作，包括子目录。

FileSystemWatcher watcher = new FileSystemWatcher
{
    Path = path,IncludeSubdirectories = true,Filter = "*.txt",NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite |
        NotifyFilters.FileName | NotifyFilters.DirectoryName
};
watcher.Created += Watcher_Created;
watcher.Changed += Watcher_Changed;
watcher.Deleted += Watcher_Deleted;
watcher.Renamed += Watcher_Renamed;
watcher.Error += Watcher_Error;
watcher.EnableRaisingEvents = true;

PS：投票不是一种选择。扫描整个 320K 目录需要 3 天时间。根级文件夹有2000多个子目录，每个子目录最多有8级子文件夹

Edit-1：我已与 INFRA 团队核对，并了解到共享文件夹位于 EMC Isilon NAS 存储上。

https://social.msdn.microsoft.com/Forums/vstudio/en-US/38adb37d-bbfc-40d6-8b32-a5c1c7d8d4a3/are-there-any-limitations-of-filesystemwatcher-monitoring-a-unc-path-on-nas-server?forum=netfxbcl

解决方法

与其同步执行事件处理程序，不如将它们卸载到 ThreadPool。这将最大限度地减少 FileSystemWatcher 内部缓冲区溢出的风险。下面的 Offload 方法可用于此目的：

public static FileSystemEventHandler Offload(FileSystemEventHandler handler)
{
    return (s,e) => ThreadPool.QueueUserWorkItem(_ => handler(s,e));
}

用法示例：

var fsw = new FileSystemWatcher(path);
fsw.Created += Offload((s,e) =>
{
    Console.WriteLine($"Created: {e.Name}");
});

这不是一个有效的解决方案，而是一个简单的缓冲区溢出问题的解决方案（假设这是您观察到的问题的原因）。