为什么 Windows 中存在 260 个字符的路径长度限制？

Why does the 260 character path length limit exist in Windows?

提问by Jeffrey Cameron

I have come up against this problem a few times at inopportune moments:

我在不合时宜的时候遇到过几次这个问题：

• Trying to work on open source Java projects with deep paths
• Storing deep Fitnesse wiki trees in source control
• An error trying to use Bazaar to import my source control tree

• 尝试从事具有深度路径的开源 Java 项目
• 在源代码管理中存储深度 Fitnesse wiki 树
• 尝试使用 Bazaar 导入我的源代码管理树时出错

Why does this limit exist?

为什么会存在这个限制？

Why hasn't it been removed yet?

为什么还没有被删除？

How do you cope with the path limit? And no, switching to Linux or Mac OS X is not a valid answer to this question ;)

你如何应对路径限制？不，切换到 Linux 或 Mac OS X 不是这个问题的有效答案；)

采纳答案by valli

Quoting this article https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

引用这篇文章https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

最大路径长度限制

在 Windows API 中（以下段落中讨论了一些例外情况），路径的最大长度是MAX_PATH，它被定义为 260 个字符。本地路径按以下顺序构造：驱动器号、冒号、反斜杠、由反斜杠分隔的名称组件和终止空字符。例如，驱动器 D 上的最大路径是“D:\ some 256-character path string<NUL>”，其中“<NUL>”表示当前系统代码页的不可见终止空字符。（此处使用字符 < > 是为了使视觉清晰，不能是有效路径字符串的一部分。）

Now we see that it is 1+2+256+1 or [drive][:\][path][null] = 260. One could assume that 256 is a reasonable fixed string length from the DOS days. And going back to the DOS APIs we realize that the system tracked the current path per drive, and we have 26 (32 with symbols) maximum drives(and current directories).

现在我们看到它是 1+2+256+1 或 [drive][:\][path][null] = 260。可以假设 256 是 DOS 时代的合理固定字符串长度。回到 DOS API，我们意识到系统跟踪每个驱动器的当前路径，我们有26 个（32 个带符号）最大驱动器（和当前目录）。

The INT 0x21 AH=0x47 says “This function returns the path description without the drive letter and the initial backslash.” So we see that the system stores the CWD as a pair (drive, path) and you ask for the path by specifying the drive (1=A, 2=B, …), if you specify a 0 then it assumes the path for the drive returned by INT 0x21 AH=0x15 AL=0x19. So now we know why it is 260 and not 256, because those 4 bytes are not stored in the path string.

INT 0x21 AH=0x47 表示“此函数返回没有驱动器号和初始反斜杠的路径描述。” 所以我们看到系统将 CWD 存储为一对（驱动器，路径），并且您通过指定驱动器（1=A，2=B，...）来请求路径，如果您指定 0，则它假定路径为INT 0x21 AH=0x15 AL=0x19 返回的驱动器。所以现在我们知道为什么它是 260 而不是 256，因为那 4 个字节没有存储在路径字符串中。

Why a 256 byte path string, because 640K is enough RAM.

为什么是 256 字节的路径字符串，因为 640K 是足够的 RAM。

回答by softveda

This is not strictly true as the NTFS filesystem supports paths up to 32k characters. You can use the win32 api and "\\?\" prefix the path to use greater than 260 characters.

这并不严格，因为 NTFS 文件系统支持最多 32k 个字符的路径。您可以使用 win32 api 和“ \\?\”前缀以使用大于 260 个字符的路径。

A detailed explanation of long path from the .Net BCL team blog.
A small excerpt highlights the issue with long paths

.Net BCL 团队博客中对 long path 的详细解释。
一小段摘录突出了长路径的问题

Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \\?\prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

另一个问题是暴露长路径支持会导致不一致的行为。带有\\?\前缀的长路径可用于大多数与文件相关的 Windows API，但并非所有 Windows API。例如，LoadLibrary 将模块映射到调用进程的地址，如果文件名长于 MAX_PATH，则失败。因此，这意味着 MoveFile 将允许您将 DLL 移动到路径长度超过 260 个字符的位置，但是当您尝试加载 DLL 时，它会失败。在整个 Windows API 中都有类似的例子；存在一些变通方法，但它们是根据具体情况而定的。

回答by Ian Boyd

The question is whydoes the limitation still exist. Surely modern Windows can increase the side of MAX_PATHto allow longer paths. Why has the limitation not been removed?

问题是为什么限制仍然存在。当然，现代 Windows 可以增加边MAX_PATH以允许更长的路径。为什么限制没有解除？

• The reason it cannot be removed is that Windows promised it would never change.

• 它不能被删除的原因是 Windows 承诺它永远不会改变。

Through API contract, Windows has guaranteed all applications that the standard file APIs will never return a path longer than 260characters.

通过 API 合同，Windows 向所有应用程序保证标准文件 API 永远不会返回长度超过260字符的路径。

Consider the following correctcode:

考虑以下正确的代码：

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows guaranteedmy program that it would populate my WIN32_FIND_DATAstructure:

Windows保证我的程序会填充我的WIN32_FIND_DATA结构：

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

My application didn't declare the value of the constant MAX_PATH, the Windows API did. My application used that defined value.

我的应用程序没有声明常量的值MAX_PATH，Windows API 做了。我的应用程序使用了该定义的值。

My structure is correctly defined, and only allocates 592bytes total. That means that i am only able to receive a filename that is less than 260characters. Windows promisedme that if i wrote my application correctly, my application would continue to work in the future.

我的结构定义正确，只分配592总字节数。这意味着我只能接收小于260字符的文件名。Windows向我保证，如果我正确编写了我的应用程序，我的应用程序将来会继续工作。

If Windows were to allow filenames longer than 260characters then my existing application (which used the correct API correctly) would fail.

如果 Windows 允许文件名长于260字符，那么我现有的应用程序（正确使用了正确的 API）将失败。

For anyone calling for Microsoft to change the MAX_PATHconstant, they first need to ensure that no existing application fails. For example, i still own and use a Windows application that was written to run on Windows 3.11. It still runs on 64-bit Windows 10. That is what backwards compatibility gets you.

对于任何要求 Microsoft 更改MAX_PATH常量的人，他们首先需要确保没有现有应用程序失败。例如，我仍然拥有并使用一个为在 Windows 3.11 上运行而编写的 Windows 应用程序。它仍然可以在 64 位 Windows 10 上运行。这就是向后兼容性为您提供的好处。

Microsoft didcreate a way to use the full 32,768 path names; but they had to create a new API contract to do it. For one, you should use the Shell APIto enumerate files (as not all files exist on a hard drive or network share).

微软确实创造了一种使用完整的 32,768 个路径名的方法；但他们必须创建一个新的 API 合同才能做到这一点。一方面，您应该使用Shell API来枚举文件（因为并非所有文件都存在于硬盘驱动器或网络共享上）。

But they also have to not break existing user applications. The vast majority of applications do notuse the shell api for file work. Everyone just calls FindFirstFile/FindNextFileand calls it a day.

但他们也必须不破坏现有的用户应用程序。绝大多数应用程序不使用 shell api 进行文件工作。每个人都只是打电话给FindFirstFile/FindNextFile并称它为一天。

回答by Root Loop

From Windows 10. you can remove the limitationby modifying a registry key.

从 Windows 10 开始，您可以通过修改注册表项来消除限制。

TipStarting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Type: REG_DWORD). The key's value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (list follows). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set. The registry key can also be controlled via Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. You can also enable the new long path behavior per app via the manifest:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

提示从 Windows 10 版本 1607 开始，MAX_PATH 限制已从常见的 Win32 文件和目录函数中删除。但是，您必须选择加入新行为。

注册表项允许您启用或禁用新的长路径行为。要启用长路径行为，请将注册表项设置为HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled（类型：）REG_DWORD。在第一次调用受影响的 Win32 文件或目录函数（列表如下）后，键的值将由系统（每个进程）缓存。在进程的生命周期内不会重新加载注册表项。为了让系统上的所有应用程序都能识别密钥的值，可能需要重新启动，因为某些进程可能在设置密钥之前已经启动。注册表项也可以通过组策略控制Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths。您还可以通过清单为每个应用启用新的长路径行为：

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

回答by jonchang

You can mount a folder as a drive. From the command line, if you have a path C:\path\to\long\folderyou can map it to drive letter X:using:

您可以将文件夹安装为驱动器。从命令行，如果您有路径，则C:\path\to\long\folder可以X:使用以下方法将其映射到驱动器号：

subst x: \path\to\long\folder

回答by JDiMatteo

One way to cope with the path limit is to shorten path entries with symbolic links.

应对路径限制的一种方法是使用符号链接缩短路径条目。

For example:

例如：

1. create a C:\pdirectory to keep short links to long paths
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. add C:\p\footo your path instead of the long path

1. 创建一个C:\p目录以保留指向长路径的短链接
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. 添加C:\p\foo到您的路径而不是长路径

回答by MovGP0

You can enable long path names using PowerShell:

您可以使用 PowerShell 启用长路径名：

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Another Version is to use a Group Policy in Computer Configuration/Administrative Templates/System/Filesystem:

另一个版本是使用组策略Computer Configuration/ Administrative Templates/ System/ Filesystem：

回答by Conrad

As to whythis still exists - MS doesn't consider it a priority, and values backwards compatibility over advancing their OS (at least in this instance).

至于为什么这仍然存在 - MS 不认为它是一个优先事项，并且重视向后兼容性而不是推进他们的操作系统（至少在这种情况下）。

A workaround I use is to use the "short names" for the directories in the path, instead of their standard, human-readable versions. So e.g.for C:\Program Files\I would use C:\PROGRA~1\You can find the short name equivalents using dir /x.

我使用的一种解决方法是对路径中的目录使用“短名称”，而不是它们的标准、人类可读的版本。因此，例如，C:\Program Files\我会使用C:\PROGRA~1\您可以使用dir /x.

回答by Priidu Neemre

As to how to cope with the path size limitation on Windows - using 7zipto pack (and unpack) your path-length sensitive files seems like a viable workaround. I've used it to transport several IDE installations (those Eclipse plugin paths, yikes!) and piles of autogenerated documentation and haven't had a single problem so far.

至于如何应对 Windows 上的路径大小限制 - 使用7zip打包（和解包）您的路径长度敏感文件似乎是一种可行的解决方法。我已经用它来传输几个 IDE 安装（那些 Eclipse 插件路径，哎呀！）和成堆的自动生成的文档，到目前为止还没有遇到任何问题。

Not really sure how it evades the 260 char limit set by Windows (from a technical PoV), but hey, it works!

不太确定它如何规避 Windows 设置的 260 个字符限制（来自技术 PoV），但是，嘿，它有效！

More details on their SourceForge page here:

有关他们的 SourceForge 页面的更多详细信息，请访问：

"NTFS can actually support pathnames up to 32,000 characters in length."

7-zip also support such long names.

But it's disabled in SFX code. Some users don't like long paths, since they don't understand how to work with them. That is why I have disabled it in SFX code.

“NTFS 实际上可以支持长达 32,000 个字符的路径名。”

7-zip 也支持这样的长名称。

但它在 SFX 代码中被禁用。有些用户不喜欢长路径，因为他们不知道如何使用它们。这就是我在 SFX 代码中禁用它的原因。

and release notes:

和发行说明：

9.32 alpha 2013-12-01

• Improved support for file pathnames longer than 260 characters.

4.44 beta 2007-01-20

• 7-Zip now supports file pathnames longer than 260 characters.

9.32 阿尔法 2013-12-01

• 改进了对超过 260 个字符的文件路径名的支持。

4.44 测试版 2007-01-20

• 7-Zip 现在支持超过 260 个字符的文件路径名。

IMPORTANT NOTE:For this to work properly, you'll need to specify the destination path in the 7zip"Extract" dialog directly, rather than dragging & dropping the files into the intended folder. Otherwise the "Temp" folder will be used as an interim cache and you'll bounce into the same 260 char limitation once Windows Explorer starts moving the files to their "final resting place". See the replies to this questionfor more information.

重要说明：为了使其正常工作，您需要直接在7zip“提取”对话框中指定目标路径，而不是将文件拖放到预期的文件夹中。否则，“Temp”文件夹将用作临时缓存，一旦 Windows 资源管理器开始将文件移动到它们的“最终放置位置”，您将反弹到相同的 260 个字符限制。有关更多信息，请参阅对此问题的答复。

回答by Sergey Dryganets

It does, and it is a default for some reason, but you could easily override it with this registry key:

确实如此，并且出于某种原因它是默认设置，但您可以使用以下注册表项轻松覆盖它：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

See: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

请参阅：https: //blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/