FileSystemWatcher的陷阱 [英] FileSystemWatcher pitfalls

问题描述

我正在开发一个C＃程序，该程序需要使用 FileSystemWatcher 类，以便在创建新文件时得到通知。作为初始化的一部分，程序将扫描目录，以便它可以处理其中已存在的任何文件。一切正常。

I am working on a C# program that needs to use the FileSystemWatcher class so it will be notified when new files are created. As part of the initialization, the program scans the directory so it can process any files that already exist in it. This is all working fine.

但是，在与另一位开发人员的讨论中，我们开始质疑这是否始终有效。 FileSystemWatcher 是否在某些情况下会丢失文件的创建？如果是这样，这些条件是什么？

However, in a discussion with another developer, we started questioning whether this will always work. Are there conditions under which the FileSystemWatcher will miss the creation of files? If so, what are these conditions?

为了处理这种情况，我们只需要在初始化过程中运行定期扫描目录的代码，但是

In order to handle this scenario, we would just run the code in our initialization process that scans the directory periodically, but how likely is it for the FileSystemWatcher to miss files?

推荐答案

<$ c $会导致 FileSystemWatcher 丢失文件吗？ c> FileSystemWatcher 不会通常丢失文件。但是：

FileSystemWatcher will not usually miss files. However:

• 由于它基于 ReadDirectoryChangesW ，因此它仅检测文件的更改。目录条目，而不更改文件本身。对文件的大多数更改都会更新目录条目，但也有一些例外（请参见这篇文章）。


• 用于文件更改通知的缓冲区大小有限；如果您没有足够快地处理事件，则缓冲区将溢出，从而导致您错过事件。这就是为什么您不应该在事件处理程序中进行任何繁重的处理的原因；如果您不能足够快地处理事件，只需将它们添加到在另一个线程上处理的队列即可。

• since it's based on ReadDirectoryChangesW, it only detects changes to the file's directory entry, not changes to the file itself. Most changes to the file will update the directory entry, but there are a few exceptions (see this article).
• the buffer for file change notifications has a limited size; if you don't process the events fast enough, the buffer will overflow, causing you to miss events. That's why you should not do any heavy processing in the event handler; if you can't handle the events fast enough, just add them to a queue that you process on another thread.

其他陷阱：

• 通知不会立即到达；实际更改和通知之间的延迟通常很短，但我发现它会延长到几秒钟。对于大多数用例来说，这不是主要问题，但是取决于您要执行的操作，可能是一个问题。


• 没有事件已移动。如果将文件从目录移动到另一个目录，则会收到两个通知：已删除和已创建


• 有时，取决于卷配置，通知中的路径可以采用旧的8.3格式（例如，您可以获取 SOMETH〜1.TXT 而不是 Something.txt ）


• 如果将现有的非空目录移动到监视目录中，则只会得到一个通知目录本身，而不是目录内容。您需要手动检查内容。


• Changed 事件对于同一文件可能会发生多次。您需要自己处理重复项

• The notifications don't arrive instantly; the delay between the actual change and the notification is usually very short, but I've seen it grow to as long as several seconds. This is not a major issue for most use cases, but depending on what you're trying to do, it could be a problem.
• There is no event for Moved. If you move a file from a directory to another, you will receive two notifications : Deleted and Created
• Sometimes, depending on the volume configuration, the paths in the notifications can be in the old 8.3 format (e.g. you can get SOMETH~1.TXT instead of Something.txt)
• If you move an existing, non-empty directory into the watched directory, you will only get a notification for the directory itself, not its content. You will need to examine the content manually.
• Changed events can occur several times for the same file; you need to handle the duplicates yourself

这篇关于FileSystemWatcher的陷阱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！