如何避免System.IO.PathTooLongException?

我们经常遇到这个问题

例:

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

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

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

试试这个: 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一样使用普通的文件和目录对象

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

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

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

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

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

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

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

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

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

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

在C#中,这是一个解决方法:

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

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