Windows FindFirstFile/FindNextFile查找已使用SHFileOperation删除的文件夹

我正在使用

FindFirstFile

和

FindNextFile

显示应用程序中给定文件夹中的文件列表

有时，我会看到我的应用程序使用

SHFileOperation

删除文件夹，但该文件夹仍然可以通过

FindFirstFile

找到。我以前在StackOverflow上看到过此问题的报告：。但是，在我的情况下，我没有使用

删除

，即使清除回收站，文件夹仍然可见。此外，该文件夹在Windows文件资源管理器中不可见。这让我想知道文件资源管理器在过滤什么以忽略该文件

---

我试图查看文件属性，但只发现删除的文件夹设置了

file\u ATTRIBUTE\u目录

和

file\u ATTRIBUTE\u VIRTUAL

。

FILE\u ATTRIBUTE\u VIRTUAL

属性有点神秘（MSDN说它是为系统使用保留的），所以我尝试忽略设置了该属性的文件夹。但是，事实证明，存在设置了此属性的合法现有/活动文件夹，因此我无法将其用作筛选器

---

为什么会显示此文件夹？如何忽略它而不忽略现有（未删除）文件夹？

我在MSDN页面上找到了这句话

请注意，其他线程或进程可能会创建或删除 在查询结果和 你根据信息采取行动的时间。如果这是一个潜在的问题 在应用程序中，一种可能的解决方案是使用CreateFile 使用CREATE_NEW（如果文件存在，则会失败）或 打开_EXISTING（如果文件不存在，则会失败）

---

它说您应该使用CreateFile API仔细检查文件是否确实存在。

删除目录是一件非常危险的事情，它经常被另一个应用程序锁定。标准情况是它是另一个进程的默认工作目录，由FileSystemWatcher、搜索索引器或反恶意软件程序通过目录中的文件进行观察。所有这些都需要做一些事情来避免很难删除目录。它们通过删除共享打开文件和目录句柄。它允许进程删除目录。但是文件和目录不会消失，直到最后一个句柄被关闭。@HansPassant删除文件夹时当然要小心。但我要重申：如果文件夹上还有一个打开的句柄，因此还不能真正删除，为什么

SHFileObject

delete操作成功了，为什么文件夹没有显示在Windows文件资源管理器中？很明显，该程序正在以某种方式过滤掉这个文件夹，这在查看属性的

FindFirstFile

文档时并不明显。没有什么特别的魔力。SHFileObject（）的优点在于它是一个shell函数，因此可以让Explorer知道它应该隐藏目录。查看SHChangeNotify（）的文档，了解其背后的管道。

文件属性虚拟

意味着它是一个文件/目录，实际上存在于32位应用程序中，它没有显示为

请求执行级别

，因此不存在。实际文件/目录位于用户的虚拟文件存储“%LocalAppdata%\VirtualStore”中。您可以在任务管理器或Process Explorer中检查是否为您的应用程序启用了UAC虚拟化。如果您的应用程序是虚拟化的，它会在受保护的系统目录中看到文件，这些文件实际上位于用户的

“%LocalAppData%\VirtualStore”

。Explorer不会看到这些虚拟文件，因为它是一个支持UAC的64位应用程序，因此没有虚拟化。