C# FileSystemWatcher 与轮询以监视文件更改

FileSystemWatcher vs polling to watch for file changes

提问by Jon Tackabury

I need to setup an application that watches for files being created in a directory, both locally or on a network drive.

我需要设置一个应用程序来监视在本地或网络驱动器上的目录中创建的文件。

Would the FileSystemWatcheror polling on a timer would be the best option. I have used both methods in the past, but not extensively.

请问FileSystemWatcher一个计时器或投票将是最好的选择。我过去使用过这两种方法，但没有广泛使用。

What issues (performance, reliability etc.) are there with either method?

这两种方法存在哪些问题（性能、可靠性等）？

采纳答案by Jason Hymanson

I have seen the file system watcher fail in production and test environments. I now consider it a convenience, but I do not consider it reliable. My pattern has been to watch for changes with the files system watcher, but poll occasionally to catch missing file changes.

我已经看到文件系统观察程序在生产和测试环境中失败。我现在认为它很方便，但我认为它不可靠。我的模式是使用文件系统观察器观察更改，但偶尔轮询以捕获丢失的文件更改。

Edit: If you have a UI, you can also give your user the ability to "refresh" for changes instead of polling. I would combine this with a file system watcher.

编辑：如果您有 UI，您还可以让您的用户能够“刷新”更改而不是轮询。我会将它与文件系统观察器结合起来。

回答by chilltemp

Also note that file system watcher is not reliable on file shares. Particularly if the file share is hosted on a non-windows server. FSW should not be used for anything critical. Or should be used with an occasional poll to verify that it hasn't missed anything.

另请注意，文件系统观察程序在文件共享上不可靠。特别是如果文件共享托管在非 Windows 服务器上。FSW 不应用于任何关键的事情。或者应该与偶尔的民意调查一起使用以验证它没有遗漏任何东西。

回答by Brent Rockwood

The FileSystemWatchermay also miss changes during busy times, if the number of queued changes overflows the buffer provided. This is not a limitation of the .NET class per se, but of the underlying Win32 infrastructure. In our experience, the best way to minimize this problem is to dequeue the notifications as quickly as possible and deal with them on another thread.

的FileSystemWatcher也可能错过在繁忙时间的变化，如果排队改变的次数溢出提供的缓冲液中。这不是 .NET 类本身的限制，而是底层 Win32 基础结构的限制。根据我们的经验，最小化此问题的最佳方法是尽快将通知出列并在另一个线程上处理它们。

As mentioned by @ChillTemp above, the watcher may not work on non-Windows shares. For example, it will not work at all on mounted Novell drives.

正如上面@ChillTemp 所提到的，观察者可能无法在非 Windows 共享上工作。例如，它在安装的 Novell 驱动器上根本不起作用。

I agree that a good compromise is to do an occasional poll to pick up any missed changes.

我同意一个很好的折衷方法是偶尔进行一次民意调查以找出任何遗漏的更改。

回答by Jon Norton

I have run into trouble using FileSystemWatcheron network shares. If you're in a pure Windows environment, it might not be an issue, but I was watching an NFS share and since NFS is stateless, there was never a notification when the file I was watching changed.

我在使用FileSystemWatcher网络共享时遇到了麻烦。如果您在纯 Windows 环境中，这可能不是问题，但我正在查看 NFS 共享，并且由于 NFS 是无状态的，因此当我正在查看的文件发生更改时，从来没有通知。

回答by Jon Norton

I'd go with polling.

我会去投票。

Network issues cause the FileSystemWatcherto be unreliable (even when overloading the error event).

网络问题导致FileSystemWatcher不可靠（即使在错误事件过载时）。

回答by Jim

Personally, I've used the FileSystemWatcheron a production system, and it has worked fine. In the past 6 months, it hasn't had a single hiccup running 24x7. It is monitoring a single local folder (which is shared). We have a relatively small number of file operations that it has to handle (10 events fired per day). It's not something I've ever had to worry about. I'd use it again if I had to remake the decision.

就我个人而言，我已经FileSystemWatcher在生产系统上使用了它，并且运行良好。在过去的 6 个月中，它 24x7 没有出现任何问题。它正在监视单个本地文件夹（共享）。我们需要处理的文件操作相对较少（每天触发 10 个事件）。这不是我曾经需要担心的事情。如果我不得不重新做出决定，我会再次使用它。

回答by PersistenceOfVision

I currently use the FileSystemWatcheron an XML file being updated on average every 100 milliseconds.

我目前FileSystemWatcher在平均每 100 毫秒更新一次的 XML 文件上使用。

I have found that as long as the FileSystemWatcheris properly configured you should never have problems with localfiles.

我发现只要FileSystemWatcher配置正确，本地文件就永远不会出现问题。

I have no experience on remote file watching and non-Windows shares.

我没有远程文件查看和非 Windows 共享方面的经验。

I would consider polling the file to be redundant and not worth the overhead unless you inherently distrust the FileSystemWatcheror have directly experienced the limitations everyone else here has listed (non-Windows shares, and remote file watching).

我会认为轮询文件是多余的并且不值得开销，除非您天生不信任FileSystemWatcher或直接经历了此处列出的其他所有人的限制（非 Windows 共享和远程文件监视）。

回答by Treb

I had some big problems with FSW on network drives: Deleting a file always threw the error event, never the deleted event. I did not find a solution, so I now avoid the FSW and use polling.

我在网络驱动器上使用 FSW 时遇到了一些大问题：删除文件总是抛出错误事件，而不是删除事件。我没有找到解决方案，所以我现在避免使用 FSW 并使用轮询。

Creation events on the other hand worked fine, so if you only need to watch for file creation, you can go for the FSW.

另一方面，创建事件运行良好，因此如果您只需要监视文件创建，则可以使用 FSW。

Also, I had no problems at all on local folders, no matter if shared or not.

此外，无论是否共享，我对本地文件夹都没有任何问题。

回答by Treb

The biggest problem I have had is missing files when the buffer gets full. Easy as pie to fix--just increase the buffer. Remember that it contains the file names and events, so increase it to the expected amount of files (trial and error). It does use memory that cannot be paged out, so it could force other processes to page if memory gets low.

我遇到的最大问题是缓冲区已满时丢失文件。很容易修复——只需增加缓冲区。请记住，它包含文件名和事件，因此将其增加到预期的文件数量（反复试验）。它确实使用了无法调出的内存，因此如果内存不足，它可能会强制其他进程进行调页。

Here is the MSDN article on buffer : FileSystemWatcher..::.InternalBufferSize Property

这是关于缓冲区的 MSDN 文章： FileSystemWatcher..::.InternalBufferSize 属性

Per MSDN:

每 MSDN：

Increasing buffer size is expensive, as it comes from non paged memory that cannot be swapped out to disk, so keep the buffer as small as possible. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties to filter out unwanted change notifications.

增加缓冲区大小的代价是昂贵的，因为它来自无法换出到磁盘的非分页内存，因此请使缓冲区尽可能小。为避免缓冲区溢出，请使用 NotifyFilter 和 IncludeSubdirectories 属性过滤掉不需要的更改通知。

We use 16MB due to a large batch expected at one time. Works fine and never misses a file.

我们使用 16MB，因为一次预计会有大批量。工作正常，不会错过任何文件。

We also read all the files before beginning to process even one...get the file names safely cached away (in our case, into a database table) then process them.

在开始处理一个文件之前，我们还读取了所有文件……将文件名安全地缓存起来（在我们的例子中，放入数据库表中）然后处理它们。

For file locking issues I spawn a process which waits around for the file to be unlocked waiting one second, then two, then four, et cetera. We neverpoll. This has been in production without error for about two years.

对于文件锁定问题，我生成了一个进程，等待文件被解锁，等待一秒钟，然后是两秒钟，然后是四秒钟，等等。我们从不投票。这已经在生产中没有错误大约两年了。

回答by ThunderGr

Using both FSW andpolling is a waste of time and resources, in my opinion, and I am surprised that experienced developers suggest it. If you need to use polling to check for any "FSW misses", then you can, naturally, discard FSW altogether and use only polling.

在我看来，同时使用 FSW和轮询是浪费时间和资源，我很惊讶有经验的开发人员建议这样做。如果您需要使用轮询来检查任何“FSW 未命中”，那么您自然可以完全丢弃 FSW 并仅使用轮询。

I am, currently, trying to decide whether I will use FSW orpolling for a project I develop. Reading the answers, it is obvious that there are cases where FSW covers the needs perfectly, while other times, you needpolling. Unfortunately, no answerhas actually dealt with the performancedifference(if there is any), only with the "reliability" issues. Is there anyone that can answer that part of the question?

目前，我正在尝试决定是否将使用 FSW或轮询来处理我开发的项目。阅读答案，很明显，在某些情况下 FSW 完美地满足了需求，而其他时候，您需要轮询。不幸的是，没有答案实际上处理性能差异（如果有的话），只有“可靠性”问题。有没有人可以回答问题的那部分？

EDIT : nmclean's point for the validity of using both FSW and polling(you can read the discussion in the comments, if you are interested) appears to be a very rational explanation why there can be situations that using both an FSW and polling isefficient. Thank you for shedding light on that for me(and anyone else having the same opinion), nmclean.

编辑： nmclean关于同时使用 FSW 和轮询的有效性的观点（如果您感兴趣，可以阅读评论中的讨论）似乎是一个非常合理的解释，为什么会出现同时使用 FSW 和轮询的情况高效的。感谢您为我（以及其他有相同意见的人）阐明这一点，nmclean。