当文件活动很多时，Internet上有很多有关ReadDirectoryChangesW API函数缺少文件的帖子。最怪罪的是调用DirectDirectoryChangesW函数循环的速度。这是一个错误的假设。我见过的最好的解释是在以下帖子中，2008年4月14日，星期一，2:15:27 PM，评论

http://social.msdn.microsoft.com/forums/zh-CN/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/

摘要是，ReadDirectoryChangesW函数报告文件更改是因为它们离开文件写后队列，而不是添加时。而且，如果在提交之前添加了太多的内容，则我们可能会在其中一些上失去注意。如果我们只是编写一个程序以在目录中快​​速生成1000多个文件，则可以在实现中看到这一点。只需计算我们收到的文件事件通知的数量，我们就会发现有时我们不会收到所有这些通知。

问题是，有没有人找到一种可靠的方法来使用ReadDirectoryChangesW函数而不必每次都刷新卷？如果用户不是管理员，则不允许这样做，这也可能需要一些时间才能完成。

解决方案

回答

如果API不可靠，那么解决方法可能是我们唯一的选择。当然，这可能涉及跟踪lastmodified和文件名。这并不意味着我们需要在查找更改时进行轮询，而是可以使用FileSystemWatcher作为触发检查的方法。

因此，如果我们跟踪最近50到100次ReadDirectoryChangesW / FSW事件发生的时间，并且看到它被迅速调用，则可以检测到此情况并触发特殊条件以获取所有已更改的文件(并设置一个标记，以在几秒钟内暂时防止将来出现伪造的FSW事件)。

由于某些人对此解决方案的评论感到困惑，因此我建议我们监视事件从ReadDirectoryChangesW到达的速度以及事件到达的速度过快时，请尝试尝试解决方法(通常是手动扫描目录)。