有很多文件活动的时候，网上有很多关于ReadDirectoryChangesW API函数缺less文件的文章。 大多数责怪ReadDirectoryChangesW函数循环被调用的速度。 这是一个不正确的假设。 我所看到的最好的解释是在下面的post，2008年4月14日星期一下午2:15:27的评论
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/
总结是ReadDirectoryChangesW函数报告文件更改，因为它们离开文件写入队列，而不是添加它们。 如果在犯罪之前添加了太多，就会失去其中一些的注意。 你可以看到这个与你的实现，如果你只是写一个程序，以真正快速生成一个目录中的超过1000个文件。 只要记下你得到的文件事件通知的数量，你会看到有些时候你不会收到所有的事件通知。
问题是，有没有人find一个可靠的方法来使用ReadDirectoryChangesW函数，而不必每次刷新卷？ 这是不允许的，如果用户不是pipe理员，也可能需要一些时间才能完成。
如果API不可靠，那么解决方法可能是您唯一的选择。 这当然可能涉及跟踪上次修改和文件名。 这并不意味着在查找更改时需要进行轮询，而是可以使用FileSystemWatcher作为触发检查的手段。
因此，如果您记录了ReadDirectoryChangesW / FSW事件发生的最后50-100次，并且您发现它正在被快速调用，则可以检测到这一情况并触发特殊条件以获取所有已更改（并已设置）的文件一个标志，以防止未来虚假FSW事件暂时）在几秒钟内。
由于有些人对此解决方案的评论感到困惑，因此我建议您应该监视事件从ReadDirectoryChangesW到达的速度，以及到达速度太快时，尝试尝试解决方法（通常是手动扫描目录）。
我们从来没有见过ReadDirectoryChangesW 100％可靠。 但是，处理这个问题的最好办法是将“报告”与“处理”分开。
我的实现有一个线程只有一个工作，重新排队所有事件。 然后第二个线程来处理我的中间队列。 你基本上是想尽可能少地阻碍事件的报道。
在高CPU情况下，您也可能阻止观察者事件的报告。
我遇到了同样的问题。 但是，我没有找到一个保证获得所有事件的解决方案。 在几次测试中，我知道应该在GetQueuedCompletionStatus函数返回后尽快再次调用ReadDirectoryChangesW函数。 我猜如果文件系统的处理速度比我的应用程序处理速度快，应用程序可能会失去一些事件。
无论如何，我将一个解析逻辑从监视逻辑中分离出来，并在一个线程上放置了一个解析逻辑。