C++ FindFirstFile、FindNextFile API是否不可靠？

出于我的目的，我想优化递归枚举Windows NTFS文件系统上给定文件夹中的子文件夹的方法，我在Microsoft的API页面上遇到了这个小“宝石”：

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

所以，让我试着去理解它

我确实依赖于

WIN32\u FIND\u DATA

结构中返回的

dwFileAttributes

参数来区分文件夹中的文件。所以这张便条表明，在某些情况下，我可能会得到一些虚假的结果，对吗？如果是这样，为什么不在他们的更新中修复它，而不是发布在这里

以及他们建议的使用GetFileInformationByHandle API的解决方法。我该怎么称呼它呢？它需要一个文件句柄。那么，他们真的希望我们打开

FindNextFile

返回的每个文件，并对其调用

GetFileInformationByHandle

？你能想象用这种方法我的优化会走多远吗

---

无论如何，如果有人能解释一下，那就太好了…

dwFileAttributes

在区分文件和文件夹之间的区别时，这并不是一件不可靠的事情。我认为该注释指的是可能被文件系统缓存以供更新的信息（修改/访问的时间戳等），但项目是文件还是文件夹并不会改变。

区分文件和文件夹是可以的，因为该信息可能是恒定的。未将文件转换为文件夹或文件夹转换为文件

---

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

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

文档通常只在容易导致严重问题（尤其是安全问题）的函数上进行注释，而不是在每个函数上都进行注释，如果不考虑这一点的话

---

如果您打开一个文件并获得它的句柄，您可以确信使用该句柄的所有操作都将指向同一个底层文件。但是，当您按名称执行操作时，没有这样的保证。可以创建、删除和重命名文件。因此，相同的名称以后可能不会引用相同的文件。

FindxxFile返回的值是建议性的，不是权威性的。请参阅讨论。除非有人删除一个文件/文件夹，然后将一个文件夹/文件重命名为相同的名称。但他们也可以在FindNextFile返回后执行此操作，因此这里没有新问题。即使FindNextFile总是返回当前数据，您也必须处理这种可能性。@RaymondChen:没错。这就是警告存在的原因之一。（一些状态报告功能有被误用的历史，或者如果被误用会产生特别严重的后果，通常会包括一个警告，即结果可能不是最新的。）“可能是恒定的”是一种轻描淡写的说法。只有当有人打开句柄进行写入时，信息才会过期，并且当有人向文件写入时，您无法将文件更改为文件夹。