blocks|key|325871|text|这并不完全正确，因为NTFS文件系统支持最多32k个字符的路径。您可以使用win32接口并在路径前加上"\\?\“前缀，以使用超过260个字符。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|325872|来自.Net+BCL+team+blog的长路径的详细说明。|325873|一小段摘录突出了长路径的问题|325874|325875|另一个问题是暴露长路径支持可能导致的不一致行为。大多数与文件相关的Windows都可以使用带有\\?\前缀的长路径，但并非所有Windows都可以使用。例如，如果文件名大于MAX_PATH，则将模块映射到调用进程的地址的LoadLibrary将失败。因此，这意味着MoveFile将允许您将动态链接库移动到某个位置，使其路径超过260个字符，但是当您尝试加载动态链接库时，它将失败。在所有Windows中都有类似的示例；存在一些变通方法，但它们是基于具体情况的。|blockquote|325876|325877|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx^0|1G|4|0|7|D|0|0|0|0|1B|4|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|I|5|6|7|13|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|14|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|18|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]]]

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

A detailed explanation of long path from the .Net <a href="http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx" rel="noreferrer">BCL team blog</a>. 
A small excerpt highlights the issue with long paths

<blockquote>
 Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the <code>\\?\</code> 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.
</blockquote>

blocks|key|3074788|text|您可以将文件夹挂载为驱动器。在命令行中，如果您有路径C:\path\to\long\folder，则可以使用以下命令将其映射到驱动器号X:：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3074789|subst+x:+\path\to\long\folder|code-block|syntax|javascript|3074790|entityMap^0|Q|M|1V|2|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

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

<pre><code>subst x: \path\to\long\folder
</code></pre>

blocks|key|323816|text|解决路径限制的一种方法是使用符号链接缩短路径条目。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323817|例如：|323818|323819|创建一个C:\p目录以将指向长路径C:\p\foo的短链接保留到您的路径，而不是长路径|ordered-list-item|offset|length|style|CODE|323820|323821|entityMap^0|0|0|0|4|4|H|8|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|R|8|@$H|S|I|T|J|K]|$H|U|I|V|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|N|$]]

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

For example:

<ol>
<li>create a <code>C:\p</code> directory to keep short links to long paths</li>
<li><code>mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo</code></li>
<li>add <code>C:\p\foo</code> to your path instead of the long path</li>
</ol>

blocks|key|323169|text|至于为什么它仍然存在-微软并不认为它是一个优先事项，而是重视向后兼容而不是推进他们的操作系统(至少在这种情况下)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323170|我使用的一种变通办法是对路径中的目录使用“短名称”，而不是标准的、人类可读的版本。例如，对于C:\Program+Files\，我会使用C:\PROGRA~1\，你可以使用dir+/x找到与之对应的缩写。|offset|length|style|CODE|323171|entityMap^0|0|1A|H|1W|C|2E|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|I|$]]

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

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 <code>C:\Program Files\</code> I would use <code>C:\PROGRA~1\</code> You can find the short name equivalents using <code>dir /x</code>.

blocks|key|3288329|text|问题是为什么的限制仍然存在。当然，现代的Windows可以增加MAX_PATH的侧边，以允许更长的路径。为何没有取消限制呢？|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|3288330|3288331|不能删除它的原因是Windows承诺它永远不会更改。|unordered-list-item|3288332|3288333|3288334|考虑以下正确的代码：|3288335|WIN32_FIND_DATA+findData;

FindFirstFile("C:\Contoso\*",+ref+findData);|code-block|syntax|javascript|3288336|Windows+向我的程序保证它将填充我的WIN32_FIND_DATA结构：|3288337|WIN32_FIND_DATA+{
+++DWORD++++dwFileAttributes;
+++FILETIME+ftCreationTime;
+++FILETIME+ftLastAccessTime;
+++FILETIME+ftLastWriteTime;
+++//...
+++TCHAR++++cFileName[MAX_PATH];
+++//..
}|3288338|我的应用程序没有声明常量MAX_PATH的值，而是Windows+API声明的。我的应用程序使用了这个定义值。|3288339|我的结构定义正确，总共只分配592字节。这意味着我只能接收少于260个字符的文件名。Windows+向承诺，如果我正确编写了应用程序，我的应用程序将来将继续工作。|3288340|如果Windows允许文件名超过260字符，那么我的现有应用程序(正确使用了正确的API+)将会失败。|3288341|它仍然可以在64位的Windows10上运行，这就是向后兼容给你带来的好处。|3288342|Microsoft确实创建了一种使用完整32,768路径名的方法；但他们必须创建一个新的契约来实现这一点。首先，您应该使用Shell+API来枚举文件(因为并非所有文件都存在于硬盘驱动器或网络共享中)。|3288343|但它们也不能破坏现有的用户应用程序。绝大多数应用程序不使用shell+api+文件工作。每个人都会给FindFirstFile/FindNextFile打电话，然后就到此为止了。|3288344|entityMap^0|3|3|V|8|0|0|0|0|0|4|3|0|0|8|V|L|F|0|0|0|1J|C|8|0|0|29|E|3|V|3|0|0|1F|G|3|0|0|12|0|0|2T|0|0|2H|1E|D|1S|C|0^^$0|@$1|2|3|4|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|1G|8|@]|E|@]|F|$]]|$1|H|3|I|5|J|7|1H|8|@]|E|@]|F|$]]|$1|K|3|-4|5|6|7|1I|8|@]|E|@]|F|$]]|$1|L|3|-4|5|6|7|1J|8|@]|E|@]|F|$]]|$1|M|3|N|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|E|@]|F|$]]|$1|O|3|P|5|Q|7|1N|8|@]|E|@]|F|$R|S]]|$1|T|3|U|5|6|7|1O|8|@$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|D]]|E|@]|F|$]]|$1|V|3|W|5|Q|7|1T|8|@]|E|@]|F|$R|S]]|$1|X|3|Y|5|6|7|1U|8|@$9|1V|A|1W|B|C]|$9|1X|A|1Y|B|D]]|E|@]|F|$]]|$1|Z|3|10|5|6|7|1Z|8|@$9|20|A|21|B|C]|$9|22|A|23|B|D]|$9|24|A|25|B|D]]|E|@]|F|$]]|$1|11|3|12|5|6|7|26|8|@$9|27|A|28|B|C]|$9|29|A|2A|B|D]]|E|@]|F|$]]|$1|13|3|14|5|6|7|2B|8|@$9|2C|A|2D|B|C]]|E|@]|F|$]]|$1|15|3|16|5|6|7|2E|8|@$9|2F|A|2G|B|C]]|E|@]|F|$]]|$1|17|3|18|5|6|7|2H|8|@$9|2I|A|2J|B|C]|$9|2K|A|2L|B|D]|$9|2M|A|2N|B|D]]|E|@]|F|$]]|$1|19|3|-4|5|6|7|2O|8|@]|E|@]|F|$]]]|1A|$]]

The question is why does the limitation still exist. Surely modern Windows can increase the side of <code>MAX_PATH</code> to allow longer paths. Why has the limitation not been removed?

<ul>
<li>The reason it cannot be removed is that Windows promised it would never change.</li>
</ul>

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

Consider the following correct code:

<pre><code>WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);
</code></pre>

Windows guaranteed my program that it would populate my <code>WIN32_FIND_DATA</code> structure:

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

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

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

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

For anyone calling for Microsoft to change the <code>MAX_PATH</code> constant, 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 did create 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 API to enumerate files (as not all files exist on a hard drive or network share).

But they also have to not break existing user applications. The vast majority of applications do not use the shell api for file work. Everyone just calls <code>FindFirstFile</code>/<code>FindNextFile</code> and calls it a day.

blocks|key|3075056|text|至于如何应对Windows上的路径大小限制-使用7zip打包(和解包)路径长度敏感的文件似乎是一个可行的解决办法。我已经用它传输了几个IDE安装(那些Eclipse插件路径，呀！)和成堆的自动生成的文档，到目前为止还没有出现任何问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3075057|我不太确定它是如何逃脱Windows设置的260字符限制的(来自技术上的PoV)，但是嘿，它是有效的！|3075058|在他们的SourceForge页面here上有更多详细信息：|3075059|3075060|+"NTFS实际上可以支持长度不超过32,000个字符的路径名。“|blockquote|3075061|3075062|7-zip也支持这样的长名称。|3075063|但它在SFX代码中是禁用的。一些用户不喜欢长路径，因为他们不知道如何使用它们。这就是为什么我在SFX代码中禁用了它。|3075064|3075065|和release+notes|3075066|3075067|+9.32+alpha+2013-12-01|3075068|3075069|3075070|3075071|改进了对超过260个字符的文件路径名的支持。|unordered-list-item|3075072|3075073|4.44测试版2007-01-20|3075074|3075075|7-Zip现在支持超过260个字符的文件路径名。|3075076|3075077|重要提示：为了让它正常工作，你需要在7zip的“解压缩”对话框中直接指定目标路径，而不是将文件拖放到目标文件夹中。否则，“临时”文件夹将被用作临时缓存，一旦Windows资源管理器开始将文件移动到它们的“最终休眠位置”，您将返回到相同的260个字符限制。有关详细信息，请参阅对this+question的回复。|style|BOLD|3075078|entityMap|0|LINK|mutability|MUTABLE|url|http://www.7-zip.org/|1|http://sourceforge.net/p/sevenzip/discussion/45797/thread/b3117cf0|2|http://www.7-zip.org/history.txt|3|4|https://superuser.com/questions/302116/what-is-the-reason-for-7-zip-winrar-to-first-unzip-files-to-temp-and-then-mo^0|O|4|0|0|0|H|4|1|0|0|0|0|0|0|0|1|D|2|0|0|0|0|0|0|0|0|0|0|0|0|0|5|I|4|3|3U|D|4|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@$A|1T|B|1U|1|1V]]|C|$]]|$1|D|3|E|5|6|7|1W|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1X|8|@]|9|@$A|1Y|B|1Z|1|20]]|C|$]]|$1|H|3|-4|5|6|7|21|8|@]|9|@]|C|$]]|$1|I|3|J|5|K|7|22|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|23|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|24|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|25|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|26|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|27|8|@]|9|@$A|28|B|29|1|2A]]|C|$]]|$1|T|3|-4|5|6|7|2B|8|@]|9|@]|C|$]]|$1|U|3|V|5|K|7|2C|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|2D|8|@]|9|@]|C|$]]|$1|X|3|-4|5|6|7|2E|8|@]|9|@]|C|$]]|$1|Y|3|-4|5|6|7|2F|8|@]|9|@]|C|$]]|$1|Z|3|10|5|11|7|2G|8|@]|9|@]|C|$]]|$1|12|3|-4|5|6|7|2H|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|2I|8|@]|9|@]|C|$]]|$1|15|3|-4|5|6|7|2J|8|@]|9|@]|C|$]]|$1|16|3|17|5|11|7|2K|8|@]|9|@]|C|$]]|$1|18|3|-4|5|6|7|2L|8|@]|9|@]|C|$]]|$1|19|3|1A|5|6|7|2M|8|@$A|2N|B|2O|1B|1C]]|9|@$A|2P|B|2Q|1|2R]|$A|2S|B|2T|1|2U]]|C|$]]|$1|1D|3|-4|5|6|7|2V|8|@]|9|@]|C|$]]]|1E|$1F|$5|1G|1H|1I|C|$1J|1K]]|1L|$5|1G|1H|1I|C|$1J|1M]]|1N|$5|1G|1H|1I|C|$1J|1O]]|1P|$5|1G|1H|1I|C|$1J|1K]]|1Q|$5|1G|1H|1I|C|$1J|1R]]]]

As to how to cope with the path size limitation on Windows - using <a href="http://www.7-zip.org/" rel="nofollow noreferrer">7zip</a> to 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. 

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

More details on their SourceForge page <a href="http://sourceforge.net/p/sevenzip/discussion/45797/thread/b3117cf0" rel="nofollow noreferrer">here</a>: 

<blockquote>
 "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.
</blockquote>

and <a href="http://www.7-zip.org/history.txt" rel="nofollow noreferrer">release notes</a>:

<blockquote>
 <h2>9.32 alpha 2013-12-01</h2>
 
 <ul>
 <li>Improved support for file pathnames longer than 260 characters.</li>
 </ul>
 
 <h2>4.44 beta 2007-01-20</h2>
 
 <ul>
 <li>7-Zip now supports file pathnames longer than 260 characters.</li>
 </ul>
</blockquote>

IMPORTANT NOTE: For this to work properly, you'll need to specify the destination path in the <a href="http://www.7-zip.org/" rel="nofollow noreferrer">7zip</a> "Extract" dialog directly, rather than dragging &amp; 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 <a href="https://superuser.com/questions/302116/what-is-the-reason-for-7-zip-winrar-to-first-unzip-files-to-temp-and-then-mo">this question</a> for more information.

blocks|key|3288520|text|在Windows10中，您可以通过修改注册表项来remove+the+limitation。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3288521|3288522|+提示从Windows10版本1607开始，已从常见的Win32文件和目录函数中删除了MAX_PATH限制。但是，您必须选择接受新的行为。|blockquote|style|BOLD|3288523|3288524|注册表项允许您启用或禁用新的长路径行为。要启用长路径行为，请将注册表项设置为HKLM\SYSTEM\CurrentControlSet\Control\FileSystem+LongPathsEnabled+(类型：REG_DWORD)。在第一次调用受影响的Win32文件或目录函数(列表如下)之后，系统(每个进程)将缓存该键的值。在进程的生存期内不会重新加载注册表项。为了让系统上的所有应用程序识别密钥的值，可能需要重新启动，因为某些进程可能已在设置密钥之前启动。注册表项也可以通过Computer+Configuration+>+Administrative+Templates+>+System+>+Filesystem+>+Enable+NTFS+long+paths上的组策略进行控制。您还可以通过清单为每个应用程序启用新的长路径行为：|CODE|3288525|true+|3288526|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/aa365247%2528VS.85%2529.aspx?f=255&MSPPError=-2147217396#maxpath^0|O|L|0|0|0|1|2|0|0|12|1T|30|9|6Q|2O|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@$A|13|B|14|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|16|8|@$A|17|B|18|H|M]|$A|19|B|1A|H|M]|$A|1B|B|1C|H|M]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1D|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|Q|$R|$5|S|T|U|C|$V|W]]]]

From Windows 10. you can <a href="https://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx?f=255&amp;MSPPError=-2147217396#maxpath" rel="noreferrer">remove the limitation</a> by modifying a registry key.

<blockquote>
 Tip Starting 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 <code>HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled</code> (Type: <code>REG_DWORD</code>). 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 <code>Computer Configuration &gt; Administrative Templates &gt; System &gt; Filesystem &gt; Enable NTFS long paths</code>.
 You can also enable the new long path behavior per app via the manifest:

<pre><code>&lt;application xmlns="urn:schemas-microsoft-com:asm.v3"&gt;
 &lt;windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;
 &lt;ws2:longPathAware&gt;true&lt;/ws2:longPathAware&gt;
 &lt;/windowsSettings&gt;
&lt;/application&gt;
</code></pre>
</blockquote>

blocks|key|3075192|text|另一种应对方法是使用Cygwin，这取决于您想要对文件做什么(即Cygwin命令是否适合您的需要)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3075193|例如，它允许复制、移动或重命名甚至Windows+Explorer都不能的文件，当然也可以处理其中的内容，如md5sum、grep、gzip等。|3075194|此外，对于您正在编码的程序，您可以将它们链接到Cygwin+DLL，这将使它们能够使用长路径(我还没有测试过这一点)|3075195|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Another way to cope with it is to use Cygwin, depending on what do you want to do with the files (i.e. if Cygwin commands suit your needs)

For example it allows to copy, move or rename files that even Windows Explorer can't. Or of course deal with the contents of them like md5sum, grep, gzip, etc.

Also for programs that you are coding, you could link them to the Cygwin DLL and it would enable them to use long paths (I haven't tested this though)

blocks|key|323970|text|确实如此，出于某些原因，它是默认的，但您可以很容易地用以下注册表项覆盖它：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323971|[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001|code-block|syntax|javascript|323972|请参阅：https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/|offset|length|323973|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/^0|0|0|4|2N|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@$I|V|J|W|1|X]]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

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

<pre><code>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
</code></pre>

See: <a href="https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/" rel="noreferrer">https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/</a>

blocks|key|3075215|text|您可以使用PowerShell启用长路径名：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3075216|Set-ItemProperty+-Path+'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'+-Name+LongPathsEnabled+-Type+DWord+-Value+1+|code-block|syntax|javascript|3075217|另一个版本是在Computer+Configuration/Administrative+Templates/System/Filesystem中使用Group+Policy|offset|length|style|CODE|3075218|​|3075219|📷|atomic|3075220|3075221|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Group_Policy|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/b65fbb338327b767939fb7f9b9ec88e4.png|imageAlt^0|0|0|7|M|U|O|1J|6|1Q|A|23|C|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|18|8|@$I|19|J|1A|K|L]|$I|1B|J|1C|K|L]|$I|1D|J|1E|K|L]|$I|1F|J|1G|K|L]]|9|@$I|1H|J|1I|1|1J]]|A|$]]|$1|M|3|N|5|6|7|1K|8|@]|9|@]|A|$]]|$1|O|3|P|5|Q|7|1L|8|@]|9|@$I|1M|J|1N|1|1O]]|A|$]]|$1|R|3|N|5|6|7|1P|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]|10|$5|11|W|12|A|$13|14|15|-4]]]]

You can enable long path names using PowerShell:
<pre class="lang-none prettyprint-override"><code>Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 
</code></pre>
Another version is to use a <a href="https://en.wikipedia.org/wiki/Group_Policy" rel="nofollow noreferrer">Group Policy</a> in <code>Computer Configuration</code>/<code>Administrative Templates</code>/<code>System</code>/<code>Filesystem</code>:
<a href="https://i.stack.imgur.com/sifwu.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/sifwu.png" alt="Group Policy Editor" /></a>

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

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

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

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

文件系统

Windows

Eclipse

Linux

Java

我在不合时宜的时候遇到过这个问题几次：尝试使用深度路径处理开源Java项目在源代码控制中存储深度Fitnesse树尝试使用Bazaar导入源代码管理树时出错为什么会有这个限制呢？为什么它还没有被移除？您如何应对路径限制？不，切换到Linux或Mac不是这个问题的有效答案;)

问为什么Windows会有260个字符的路径长度限制？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Windows会有260个字符的路径长度限制？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Windows会有260个字符的路径长度限制？
EN