winapi - 我应该处理超过 MAX_PATH 的文件吗？

Question

刚刚遇到一个有趣的案例。

我的软件报告了由于路径长于 MAX_PATH 而导致的故障。

该路径只是我的文档中的一个普通的旧文档，例如:

C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf

总长度 269 个字符 (MAX_PATH==260)。

用户没有使用外部硬盘驱动器或类似的东西。这是 Windows 托管驱动器上的文件。

所以我的问题是这个。我应该关心吗？

我不是说我可以处理长路径，我问我是否应该。是的，我知道某些 Win32 API 上的“\?\”unicode hack，但似乎这种 hack 并非没有风险(如它改变了 API 解析路径的方式的行为)，并且并非所有 API 都支持。

所以无论如何，让我陈述我的立场/断言:

首先大概用户能够打破这个限制的唯一方法是她使用的应用程序是否使用了特殊的 Unicode hack。这是一个PDF文件，所以也许她使用的PDF工具使用了这个hack。

我试图重现这一点(通过使用 unicode hack)并进行了实验。我发现虽然该文件出现在资源管理器中，但我对它无能为力。我无法打开它，我无法选择“属性”(Windows 7)。其他常用应用程序无法打开该文件(例如 IE、Firefox、记事本)。 Explorer 也不会让我创建太长的文件/目录 - 它只是拒绝。命令行工具 cmd.exe 也是如此。

所以基本上，人们可以这样看待它:胭脂工具允许用户创建一个许多 Windows(例如资源管理器)无法访问的文件。我可以认为我不应该处理这个。

(顺便说一句，这不是对较短的最大路径长度的批准投票:我认为 260 个字符是一个笑话，我只是说如果 Windows shell 和某些 API 无法处理 > 260 那么我为什么要？)。

那么，这是一个公平的观点吗？我应该说“不是我的问题”吗？

更新:刚刚有另一个用户遇到了同样的问题。这次是一个mp3文件。我错过了什么吗？这些用户如何创建违反 MAX_PATH 规则的文件？

Answer 1

这不是一个真正的问题。 NTFS 最多支持文件名 32K ( 32,767 个宽字符 )。您只需要使用正确的 API 和正确的文件名语法。基本规则是:文件名应该以 '\\?\' 开头(见 http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx)喜欢 \\?\C:\Temp .可以与 UNC 一起使用的相同语法:\\?\UNC\Server\share\Path .重要的是要了解您只能使用 API 函数的一小部分。例如查看功能的MSDN描述

CreateFile
CreateDirectory 
MoveFile

and so on

你会发现像这样的文字:

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\?\" to the path. For more information, see Naming a File.

这个功能你可以放心使用。如果您有来自 CreateFile 的文件句柄您可以使用所有其他使用过的功能 hFile ( ReadFile , WriteFile 等) 没有任何限制。

如果您编写了病毒扫描程序或备份软件之类的程序或在服务器上运行的一些优秀软件，您应该编写程序，以便所有文件操作都支持最大 的文件名。 32K 字符而不是 MAX_PATH人物。