FindFirstFile，FindNextFile API不可靠吗？

对于我的目的，我希望从Windows上的NTFS文件系统上的指定文件夹优化递归枚举子文件夹的方式，和我碰到这个小“宝石”从微软的网页来抓FindFirstFile API：FindFirstFile，FindNextFile API不可靠吗？

注意在极少数情况下，或系统的负荷很重时，文件属性在NTFS文件系统信息可能不会在这个函数被调用时的电流。要确保获得当前的NTFS文件系统文件属性，请调用GetFileInformationByHandle函数。

所以，让我试着理解它。

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

而且他们建议使用GetFileInformationByHandle API的解决方法。我到底该怎么称呼它？它需要一个文件句柄。那么他们是否真的希望我们打开FindNextFile返回的每个文件并且打电话给GetFileInformationByHandle？你能想象我的优化能够在多远的情况下采用这种方法吗？

不管怎么说，这将会是好的，如果有人能提供一些线索对这个...

来源

2013-03-18 c00000fd

FindXxxFile返回的值是通知性的而非权威性的。参见讨论[here]（http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251026.aspx）。 – 2013-03-18 03:12:07

dwFileAttributes是不是将是不可靠的，当谈到告诉文件和文件夹的区别的东西。我认为这个提示指的是可能被文件系统缓存以供更新的信息（修改/访问时间戳等），但是一个项目是文件还是文件夹并不会改变。

来源

2013-03-18 03:11:58

除非有人删除文件/文件夹，然后将文件夹/文件重命名为相同的名称。 – 2013-03-18 03:25:48

但是他们也可以在FindNextFile返回后这样做，所以这里没有新问题。即使FindNextFile总是返回当前数据，您也必须处理这种可能性。 – 2013-03-18 04:46:52

@RaymondChen：确实如此。这是警告出现的原因之一。（某些状态报告功能有被滥用的历史，或者如果滥用会造成特别严重的后果，并且通常包含一个警告，说明结果可能不是最新的。） – 2013-03-18 06:59:21

从文件夹中区分文件是可以的，因为该信息可能是恒定的。文件不会被转换为文件夹或文件夹。

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

来源

2013-03-18 03:13:59

“可能是恒定的”是轻描淡写。只有当某人写入处理时，信息才会过时，并且在有人写入文件时不能将文件更改为文件夹。 – MSalters 2013-03-18 12:49:24

这是每个状态报告功能的工作方式。最好的情况是，当你调用函数和函数返回时，它会在中间某个未定义的点处报告状态。但它不会“冻结世界”以确保数据在以后仍然有效。

在没有考虑到这些因素的情况下，文档通常只记录通常会导致严重问题的功能，特别是安全问题，而不是在每个功能上注明这一点。

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

来源

2013-03-18 03:24:42

FindFirstFile，FindNextFile API不可靠吗？

回答

相关问题