刚遇到一个有意思的案例。
我的软件报告了一个由路径长度超过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,但是它似乎有风险(因为它改变了API解析路径的方式),而且也不被所有API支持。
无论如何,让我表述我的立场/观点:
- 首先,假设用户能够突破此限制的唯一方法是她使用了特殊的Unicode hack。这是一个PDF文件,所以可能是她使用的PDF工具使用了这个hack。
- 我尝试复现了这个问题(使用Unicode hack进行实验)。我发现,虽然文件出现在资源管理器中,但我无法对其进行任何操作。我不能打开它,我不能选择“属性”(在Windows 7中),其他常见应用程序也无法打开文件(例如IE、Firefox、记事本)。资源管理器也不允许我创建过长的文件/目录-它会拒绝。命令行工具cmd.exe也是如此。
因此,可以这样看待这个问题:一个流氓工具允许用户创建了一个大多数Windows(例如资源管理器)无法访问的文件。我可以认为我不应该处理这个问题。
(顺便说一句,这并不意味着我对短的最大路径长度表示赞同:我认为260个字符是个笑话,我只是在说如果Windows shell和一些API不能处理>260字符,那么我为什么要这样做?)
所以,这种观点是否公正?我应该说“不是我的问题”吗?
更新:刚刚有另一个用户遇到了同样的问题。这次是一个mp3文件。我错过了什么吗?这些用户如何创建违反MAX_PATH规则的文件?
rename "C:\Documents and Settings\Bill\New Folder" "Some Stupid FOlder Name"
。 - Adrian Pronk