如何避免System.IO.PathTooLongException？

我们经常遇到这个问题

例：

如果我有一个文件，我想将它复制到另一个目录或UNC共享，如果path的长度超过248（如果我没有弄错），那么它会抛出PathTooLongException。 有没有解决这个问题的方法？

PS：有没有任何registry设置将此path设置为较长的​​字符集？

Answer 1

如Jeremy Kuhne的博客中所述 ，.NET Framework 4.6.2在可能的情况下删除了MAX_PATH限制，而不会破坏向后兼容性。

Answer 2

试试这个： Delimon.Win32.I O Library（V4.0） 这个Libarary是用.NET Framework 4.0编写的

Delimon.Win32.IOreplace了System.IO的基本文件function，并支持最多32,767个字符的文件和文件夹名称。

https://gallery.technet.microsoft.com/DelimonWin32IO-Library-V40-7ff6b16c

此库是专门为了克服.NET Framework使用长path和文件名的限制而编写的。 有了这个库，你可以以编程方式浏览，访问，写入，删除等文件和文件夹不能被System.IO命名空间访问。

用法

1. 首先将对Delimon.Win32.IO.dll的引用添加到您的项目（浏览到Delimon.Win32.IO.dll文件）

2. 在你的代码文件中添加“使用Delimon.Win32.IO”

3. 像使用System.IO一样使用普通的文件和目录对象

Answer 3

这已经由BCL团队深入讨论，请参阅博客条目

实质上， 在.Net代码中没有办法做到这一点，并坚持BCL。 太多的函数依赖于能够规范化path名（它立即触发使用需要MAX_PATH的函数）。

你可以包装所有支持“\\？\”语法的win32函数，这样你就可以实现一套长path感知function，但是这样做会很麻烦。

由于大量的工具（包括explorer [1]）不能处理长path名，除非你很高兴与生成的文件系统的所有交互都通过你的库（或者数量有限的工具是build立处理它像robocopy）

为了回答您的具体需求，我将调查直接使用robocopy是否足以执行此任务。

[1] Vista有一些方法来缓解这个问题，在引擎盖下进行一些花哨的重命名，但是这个最好是脆弱的）

Answer 4

只有一个解决方法，我已经看到这个…这可能会有所帮助

http://www.codeproject.com/KB/files/LongFileNames.aspx

Answer 5

问题是Windows API的ANSI版本。 需要仔细testing的一个解决scheme是强制使用Unicode版本的Windows API。 这可以通过将“ \\?\ ”前置于被查询的path来完成。

包括变通方法在内的大量信息可以在Microsoft基本类库（BCL）团队的标题为“.NET中的长path”的以下博客文章中find：

• http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
• http://blogs.msdn.com/bclteam/archive/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton.aspx
• http://blogs.msdn.com/b/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx

Answer 6

我用“subst”命令来解决这个问题… http://www.techrepublic.com/article/mapping-drive-letters-to-local-folders-in-windows-xp/5975262

Answer 7

在C＃中，这是一个解决方法：

 /*make long path short by setting it to like cd*/ string path = @"\\godDamnLong\Path\"; Directory.SetCurrentDirectory(path); 

Answer 8

这个图书馆可能会有帮助： Zeta长path