0

我的 Win32 系统有一些奇怪的行为：如果我将路径传递C:/temp/file.txt.给_wfindfirstand _wfopen_s，我会得到一个成功打开的文件，尽管它只C:/temp/file.txt存在于磁盘上。

首先，我认为 the.也可能是 Win32 上可接受的通配符，但查看 Microsoft 文档

这些根本没有提到.角色。

当然，我可以在将路径放入_wfopen_sor之前检查路径_wfindfirst，但我想知道是否有其他方法可以阻止我打开具有非法路径的文件......

4

2 回答 2

1

它不是通配符。文件名末尾的点始终被省略，因此F.和F等价于所有F.

于 2012-05-16T13:20:18.357 回答
1

虽然 NTFS 本身支持文件名末尾的句点（某些客户端，如旧的 POSIX 子系统，可以使用此类文件），但 Win32 API 本身不支持，并且会'.'在打开文件时去除尾随：

CreateFile() 从文件和目录名称中删除尾随空格和句点。这样做是为了与 FAT 和 HPFS 文件系统兼容。

显然，FindFirstFile()朋友们也这样做（鉴于上述情况，这并不奇怪，但我找不到任何明确的文档这么说）。

无需直接检查输入文件名以查看它是否与您的受限制文件名之一匹配，您可以检查由返回的结构的name字段以查看它是否匹配（并对通过 and 找到的所有文件执行相同操作）。但我想这就是你要去的地方。_wfinddata_t_wfindfirst()_wfindnext()

请记住，传入 8.3 格式的文件名也可能会在name字段中返回一个完全不同的文件名（因为操作系统将长文件名映射到短文件名）。您可能需要在检查中考虑该映射，Win32 FindFirstFile()/ FindNextFile()API 可能会为您提供帮助，因为它们会返回匹配的长文件名和任何相应的短文件名。

如果您FindFirstFileW()直接使用而不是_wfindfirst()您可以检查cFileName和 cAlternatefileName` 字段以查看实际找到的文件

于 2012-05-17T07:53:39.973 回答