当有很多文件活动时，互联网上有许多关于ReadDirectoryChangesW API函数的文章缺少文件。大多数人指责调用ReadDirectoryChangesW函数循环的速度。这是一个不正确的假设。我看到的最好的解释是在下面的帖子，评论2008年4月14日星期一2:15:27 PM
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/
摘要是ReadDirectoryChangesW函数在文件写入队列离开时报告文件更改，而不是添加文件。如果在提交之前添加太多，则会丢失其中的一些信息。您可以通过实现来看到这一点，如果您只是编写一个程序，以便在目录中快速生成1000个文件。只需计算您获得多少文件事件通知，您将看到有时您将不会收到所有这些通知。
问题是，有没有人发现使用ReadDirectoryChangesW功能的可靠方法，而不必每次刷新卷？如果用户不是管理员，也可能需要一些时间才能完成此操作。
如果API不可靠，则解决方法可能是您唯一的选择。这当然可能涉及跟踪最后修改和文件名。这不意味着您需要在查找更改时进行轮询，而可以使用FileSystemWatcher作为触发检查的手段。
因此，如果您跟踪ReadDirectoryChangesW / FSW事件发生的最后50-100次，并且您看到它正在快速调用，您可以检测到这一点，并触发特殊条件以获取所有已更改的文件(并设置一个标志，以防止未来的虚假FSW事件暂时)在几秒钟内。
由于有些人对有关此解决方案的评论感到困惑，因此我建议您监控事件从ReadDirectoryChangesW获得的速度以及到达速度太快时，尝试尝试解决方法(通常是手动扫描目录)。
