如何避免System.IO.PathTooLongException？

Question

我们经常遇到这样的问题...

示例：

如果我有一个想要复制到另一个目录或UNC共享中的文件，如果路径长度超过248 (如果我没记错)，那么它就会抛出PathTooLongException。这个问题有什么解决方法吗？

PS:是否有任何注册表设置可以将此路径设置为更长的字符集？

Answer 1

正如Jeremy Kuhne的blog中所描述的，.NET框架4.6.2在可能的情况下消除了MAX_PATH的限制，而不会破坏向后兼容性。

Answer 2

试试这个：Dlimon.Win32.I Framework库(V4.0)这个库是基于.NET​4.0编写的

Win32.IO取代了System.IO的基本文件功能，并支持最多32,767个字符的文件名和文件夹名。

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

这个库是专门为克服.NET框架使用长路径和文件名的限制而编写的。使用此库，您可以通过编程方式浏览、访问、写入、删除等System.IO namespace.Library无法访问的文件和文件夹

使用

1. 首先在项目中添加对Delimon.Win32.IO.dll的引用(浏览到Delimon.Win32.IO.dll文件)
2. 在代码文件中添加“使用System.IO普通文件和目录对象，就像使用System.IO

一样

Answer 3

BCL团队已经对此进行了深入的讨论，请参阅blog entries

本质上，没有办法在.Net代码中做到这一点并坚持使用BCL。太多的函数依赖于能够规范化路径名(这会立即触发期望遵循MAX_PATH的函数的使用)。

您可以包装所有支持"\?\“语法的win32函数，使用这些函数，您将能够实现一套长路径感知功能，但这会很麻烦。

由于大量的工具(包括explorer1)不能处理长路径名，所以不建议采用这种方法，除非您很高兴与生成的文件系统的所有交互都通过您的库(或为像robocopy那样处理它而构建的有限数量的工具)。

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

1 Vista有办法通过一些花哨的重命名来缓解这个问题，但这充其量是脆弱的)