出于我的目的，我正在寻找优化从Windows上的NTFS文件系统上给定文件夹中递归枚举子文件夹的方法，我从微软的FindFirstFile API页面上遇到了这个小的"gem":
注意在少数情况下或在高负载的系统上，文件属性有关NTFS文件系统的信息可能不是当前的函数被调用。以确保获得当前的NTFS文件系统文件属性，调用GetFileInformationByHandle函数
那么，让我试着去理解它。
我确实依赖于WIN32_FIND_DATA结构体中返回的dwFileAttributes参数来区分文件和文件夹。这个笔记表明，在某些情况下，我可能会得到一些虚假的结果，对吧?如果是这样，为什么不在他们的更新中修复它，而不是在这里发布?
以及他们建议的使用GetFileInformationByHandle API的解决方案。我该怎么称呼它?它接受一个文件句柄。那么，他们真的希望我们打开FindNextFile返回的每个文件并调用GetFileInformationByHandle吗?您能想象使用这种方法我的优化能走多远吗?
无论如何，如果有人能解释一下就太好了…
区分文件和文件夹是可以的，因为这些信息很可能是恒定的。文件没有变成文件夹，文件夹也没有变成文件。
文档说"可能不是当前的"，因为其他进程可能正在更改属性，并且没有锁定机制来同步属性正在惰性地写入。如果你的应用程序需要绝对当前的信息，你检索它…
这是每个状态报告函数的工作方式。在最好的情况下，它报告在调用函数和返回函数之间某个未定义点的状态。但它不会"冻结世界"以确保数据以后仍然有效。
不是在每个函数上都注意到这一点，文档通常只在可能导致严重问题的函数上注意到这一点，特别是在没有考虑到这一点的情况下的安全性问题。
如果你打开一个文件并得到它的句柄，你可以确信所有使用这个句柄的操作都将是对同一个底层文件的操作。但是当您按名称执行操作时，就没有这样的保证了。文件可以创建、删除和重命名。因此，相同的名称以后可能不会引用相同的文件。
dwFileAttributes在区分文件和文件夹时并不是不可靠的。我认为这个注释指的是可能被文件系统缓存更新的信息(修改/访问时间戳等)，但无论一个项目是文件还是文件夹都不会改变。