我应该处理长度超过MAX_PATH的文件吗? [英] Should I deal with files longer than MAX_PATH?

问题描述

有一个有趣的案例.

我的软件报告由于路径长于MAX_PATH而导致失败.

My software reported back a failure caused by a path being longer than MAX_PATH.

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

The path was just a plain old document in My Documents, e.g.:

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).

Total length 269 characters (MAX_PATH==260).

用户未使用外部硬盘驱动器或类似设备.这是Windows托管驱动器上的文件.

The user wasn't using a external hard drive or anything like that. This was a file on an Windows managed drive.

所以我的问题是这个.我应该在乎吗?

So my question is this. Should I care?

我不是说可以我处理了很长的路，我问的是应该我.是的，我知道"\?\" unicode对某些Win32 API进行了黑客攻击，但似乎这种黑客攻击并非没有风险(因为它正在改变API解析路径的方式的行为)，并且并非所有API都支持.

I'm not saying can I deal with the long paths, I'm asking should I. Yes I'm aware of the "\?\" unicode hack on some Win32 APIs, but it seems this hack is not without risk (as it's changing the behaviour of the way the APIs parse paths) and also isn't supported by all APIs .

所以无论如何，让我只说一下我的立场/主张:

So anyway, let me just state my position/assertions:

1. 第一个大概是用户能够打破此限制的唯一方法是，如果她使用的应用程序使用特殊的Unicode hack.这是一个PDF文件，因此她使用的PDF工具可能会使用此技巧.
2. 我尝试通过使用unicode hack来重现此内容并进行了实验.我发现，尽管该文件出现在资源管理器中，但我却无能为力.我无法打开它，我无法选择属性"(Windows 7).其他常见应用程序无法打开文件(例如IE，Firefox，记事本).资源管理器也不会允许我创建太长的文件/目录-它只是拒绝.命令行工具cmd.exe也是如此.

因此，基本上，人们可以这样看:一种胭脂工具允许用户创建一个文件，该文件无法被许多Windows(例如Explorer)访问.我可以认为我不必处理这个问题.

So basically, one could look at it this way: a rouge tool has allowed the user to create a file which is not accessible by a lot of Windows (e.g. Explorer). I could take the view that I shouldn't have to deal with this.

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

(As an aside, this isn't an vote of approval for a short max path length: I think 260 chars is a joke, I'm just saying that if Windows shell and some APIs can't handle > 260 then why should I?).

那么，这是一个公平的看法吗?我应该说不是我的问题"吗?

So, is this a fair view? Should I say "Not my problem"?

更新:刚刚有另一个用户遇到相同的问题.这次是mp3文件.我想念什么吗?这些用户如何创建违反MAX_PATH规则的文件?

UPDATE: Just had another user with the same problem. This time an mp3 file. Am I missing something? How can these users be creating files that violate the MAX_PATH rule?

推荐答案

这不是真正的问题. NTFS支持的文件名最大为 32K ( 32767个宽字符).您只需要使用正确的API和文件名的正确语法即可.基本规则是:文件名应以'\\?\'开头(请参见

It's not a real problem. NTFS support filenames up to 32K (32,767 wide characters). You need only use correct API and correct syntax of filenames. The base rule is: the filename should start with '\\?\' (see http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx) like \\?\C:\Temp. The same syntax you can use with UNC: \\?\UNC\Server\share\Path. Important to understand that you can use only a small subset of API function. For example look at MSDN description of functions

CreateFile
CreateDirectory 
MoveFile

以此类推

您会发现类似的文本:

在此功能的ANSI版本中， 名称仅限于MAX_PATH 人物.将此限制扩展到 32,767个宽字符，请致电 函数的Unicode版本和 在路径前加上"\?\".欲了解更多 信息，请参阅命名文件.

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等).

This functions you can safe use. If you have a file handle from CreateFile you can use all other functions used hFile (ReadFile, WriteFile etc.) without any restriction.

如果编写诸如病毒扫描程序或备份软件之类的程序，或者在服务器上运行某些良好的软件，则应编写程序，以便所有文件操作支持的文件名最多为 32K 个字符，而不是字符.

If you write a program like virus scanner or backup software or some good software running on a server you should write your program so, that all file operations support filenames up to 32K characters and not MAX_PATH characters.

这篇关于我应该处理长度超过MAX_PATH的文件吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！