我有通过 shell API 枚举收藏夹文件夹（递归）的代码。我使用该GetAttributesOf函数来获取我找到的每个对象的属性。
因为我从不向上推进，所以我的期望是我遇到的所有项目都是文件系统对象。这可能不适用于所有子目录，但我非常有信心这对有问题的子目录是正确的。
尽管我有信心，但我确认属性包括SFGAO_FILESYSTEM. 如果他们不这样做，那么我会记录一条消息并跳过该项目，因为没有希望能够完成我的工作。我预计我永远不会看到日志记录或必须跳过一个项目，但我还是进行了验证，因为这就是我滚动的方式。
几周后，我优秀的 QA 工程师告诉我，他看到我的程序在某个特定项目上出现异常行为，大约在发生这种情况的时候，他在日志中看到该项目没有设置文件系统位，因此必须跳过。有问题的项目是，我们有充分的理由相信，一个文件。
自从我最初写这个问题以来，我们已经看到枚举中的几个项目声称不是文件系统项目的情况。麻烦似乎持续了很短的时间，但足够长的时间来搞砸多达六个项目的标志。
什么时候文件不是文件系统对象？
目前尚不清楚您使用的是旧文件系统还是 NTFS，但有几件事可能会破坏文件系统位 - Vista 引入了符号链接，这与常规快捷方式不同，因为它们解析“客户端”它们本身可能不算作文件系统对象。目录重解析点也是如此。SFGAO 枚举并不完全是 NTFS 中正在发生的事情的 1:1 表示，因此请对它的信息持保留态度。
还有一个外部机会是坏块可能导致 Windows 报告文件系统位不一致。如果相同的文件有时被报告为文件系统对象，有时则不是，那将成为您唯一的解释。
你这样做是递归的吗？
如果您进入存档（例如 zip 或 cab 文件），您将看到非文件系统对象。
同样，如果您进入包含 desktop.ini 文件的目录，您可能会看到非文件系统对象（但这取决于 desktop.ini 引用的 COM 对象的作用）。
尽管在这两种情况下，如果您尝试将对象作为文件访问，您希望看到一个未找到的错误，而不是拒绝访问。您是否有可能对违规对象没有文件系统权限？
符号链接和重解析点等 NTFS 功能被报告为文件系统对象，因此它们绝对不是问题。