FindFirstFile，FindNextFile API是否不可靠？

Question

出于我的目的，我希望优化从Windows上的NTFS文件系统上的给定文件夹递归枚举子文件夹的方法，我从微软的页面中看到了这个小“ gem ” FindFirstFile API：

  

注意在极少数情况下或在负载很重的系统上，文件属性   有关NTFS文件系统的信息在此时可能不是最新信息   函数被调用。确保获取当前的NTFS文件   系统文件属性，调用GetFileInformationByHandle函数。

所以，让我试着理解它。

我确实依赖于dwFileAttributes结构中返回的WIN32_FIND_DATA参数来告诉文件夹中的文件。所以这个说明表明，在某些情况下，我可能会得到一些虚假的结果，对吗？如果是这样，为什么不在其中一个更新中修复它而不是在此处发布？

还有他们建议的使用GetFileInformationByHandle API的解决方法。我该怎么称呼呢？它需要一个文件句柄。那么他们真的希望我们打开FindNextFile返回的每个文件并在其上调用GetFileInformationByHandle吗？你能想象我的优化会用这种方法“走多远”吗？

无论如何，如果有人可以对此有所了解，那就太好了......

Answer 1

区分文件和文件夹是可以的，因为该信息可能是不变的。文件不会转换为文件夹或文件夹到文件中。

文档说“可能不是最新的”，因为其他进程可能正在更改属性，并且没有用于同步属性的锁定机制正在懒惰地写入。如果您的应用程序需要绝对最新的信息，您可以检索它... ByHandle确保信息是最新的。

Answer 2

这是每个状态报告功能的工作方式。充其量，它会在您调用函数和函数返回时在某个未定义的点之间报告状态。但它并没有“冻结世界”以确保数据在以后仍然有效。

在没有考虑到这一点的情况下，文档通常只会注意到会导致严重问题的功能，特别是安全问题，而不会考虑到这一点。

如果您打开一个文件并获取它的句柄，那么您可以确信使用该句柄的所有操作都将使用相同的基础文件。但是当你按名称进行操作时，就没有这样的保证。可以创建，删除和重命名文件。因此，相同的名称可能以后不会引用同一个文件。

Answer 3

在描述文件和文件夹之间的差异时，

dwFileAttributes不会是不可靠的。我认为该注释指的是可能由文件系统缓存以供更新的信息（修改/访问的时间戳等），但是项目是文件还是文件夹不会发生变化。