我正在使用 Windows API 函数 FindFirstFileEx 因为它提供仅返回给定目录的子目录的功能(忽略文件)。但是,当我使用 required 标志调用此函数时,我仍然会收到文件和目录。
FindFirstFileEx 使用的 FindExSearchLimitToDirectories 标志的 MSDN 文档说:
这是一个咨询标志。如果文件
系统支持目录过滤,
该函数搜索一个文件
与指定的名称匹配,并且也是
一个目录。如果文件系统有
不支持目录过滤,这个
标志被默默地忽略。
lpSearchFilter参数
FindFirstFileEx 函数必须为 NULL
当使用此搜索值时。
如果需要目录过滤,
该标志可用于所有文件
系统,但因为它是一个咨询
标志并且仅影响文件系统
支持它,应用程序必须
检查存储的文件属性数据
在 lpFindFileData 参数中
FindFirstFileEx函数判断
函数是否返回了
目录句柄。
那么,哪些文件系统实际上支持此标志? 在同一页面上实际列出这些受支持的文件系统是明智的,但我找不到它。
我的开发系统是Windows XP SP3、NTFS、.NET 3.5。
我知道我可以检查文件属性来确定文件是否是目录,但这意味着检查每个文件/目录。它也违背了使用 FindFirstFileEx 的初衷。
当然,我仍然有可能在代码中做错了一些事情。我唯一能看到的是将 IntPtr.Zero 传递给 lpSearchFilter 可能与传递 NULL 不同(如引用中所述)。
这是我正在使用的代码示例:
m_searchDirHandle = WinAPI.FindFirstFileEx(@"C:\Temp\*",
WinAPI.FINDEX_INFO_LEVELS.FindExInfoStandard ,
ref m_findDirData, WinAPI.FINDEX_SEARCH_OPS.FindExSearchLimitToDirectories,
IntPtr.Zero , 0);
if (m_searchDirHandle != WinAPI.INVALID_HANDLE_VALUE)
{
do
{
foundNextDir = WinAPI.FindNextFile(m_searchDirHandle, ref m_findDirData);
} while (foundNextDir);
}
I am using the Windows API function FindFirstFileEx because it provides the capability to return just the sub-directories of a given directory (ignoring files). However when I call this function with the required flag, I still receive both files and directories.
The MSDN documentation for the FindExSearchLimitToDirectories flag used by FindFirstFileEx says:
This is an advisory flag. If the file
system supports directory filtering,
the function searches for a file that
matches the specified name and is also
a directory. If the file system does
not support directory filtering, this
flag is silently ignored.
The lpSearchFilter parameter of the
FindFirstFileEx function must be NULL
when this search value is used.
If directory filtering is desired,
this flag can be used on all file
systems, but because it is an advisory
flag and only affects file systems
that support it, the application must
examine the file attribute data stored
in the lpFindFileData parameter of the
FindFirstFileEx function to determine
whether the function has returned a
handle to a directory.
So, what file systems actually support this flag? It would have been sensible to actually list these supported file systems on the same page, but I can't find it.
My development system is Windows XP SP3, NTFS, .NET 3.5.
I know I can check file attributes to determine if a file is a directory, however this means checking the every file/directory. It also defeats the purpose of using FindFirstFileEx in the first place.
Of course there is still the chance I may be doing something incorrectly in my code. The only thing I can see is passing IntPtr.Zero to lpSearchFilter may not be the same as passing NULL (as mentioned in the quote).
Here's an example of the code I'm using:
m_searchDirHandle = WinAPI.FindFirstFileEx(@"C:\Temp\*",
WinAPI.FINDEX_INFO_LEVELS.FindExInfoStandard ,
ref m_findDirData, WinAPI.FINDEX_SEARCH_OPS.FindExSearchLimitToDirectories,
IntPtr.Zero , 0);
if (m_searchDirHandle != WinAPI.INVALID_HANDLE_VALUE)
{
do
{
foundNextDir = WinAPI.FindNextFile(m_searchDirHandle, ref m_findDirData);
} while (foundNextDir);
}
发布评论
评论(1)
我能找到的最近的链接是 Metasploit 的系统调用列表。 ..我在这里尝试一下,但我想这个'FindFirstFileEx'会以某种方式间接调用NT系统调用,相当于'NtOpenDirectoryObject','NtQueryDirectoryFile','NtQueryDirectoryObject'...我希望...如果有人的话认为我错了,并投反对票,不同意的人会纠正我:)
但是,我在这里点击了一些链接
编辑:刚刚在评论中提到后,我我认为添加一个指向 Linux NTFS 驱动程序 的链接就足够了,以获得以下功能:读取 NTFS 分区,必然会有源版本更改以适应回溯到 Win2000 的不同 NTFS 版本...
希望这会有所帮助,
此致,
汤姆.
The nearest link I could find was, the list of System Calls by Metasploit...I am taking a stab here but I would imagine that this 'FindFirstFileEx' would somehow be an indirect call to the NT system call equivalent 'NtOpenDirectoryObject', 'NtQueryDirectoryFile', 'NtQueryDirectoryObject'... I hope...if anyone thinks I'm wrong and downvotes to disagree, I will be corrected by whoever disagrees :)
However, I have hit on a few links here
Edit: Just now after mentioning in the comments, I thought it would be fitting enough to add a link to the Linux NTFS driver for capabilities to read the NTFS partition, there is bound to be source version changes to accomodate the different NTFS versions going back to Win2000...
Hope this helps,
Best regards,
Tom.