问题标签 [pathtoolongexception]

我有以下代码：

我通过以下行不断遇到 PathTooLongException 错误：

该应用程序钻入驱动器并找到驱动器中的所有文件/文件夹。我无法更改此路径，但由于它超过 260 个字符...如何解决此问题？

我尝试使用路径很长的 DirectoryInfo、FileInfo。

• 我尝试使用 \\?\c:\long 路径（我得到了带有 fileInfo 和 DirectoryInfo 的非法字符）
• 我尝试使用 file://c:/long 路径（我不支持 uri）

我可以在路径或其他东西中使用〜。

我读了这篇文章，但我想使用另一种调用 API 的方式。是否有其他解决方案？

微软有一篇文章供使用 \\? 在文件路径链接文本中

问题是我如何使用非常长的路径，以及超过 256 个字符的路径的 DirectoryInfo 和 FileInfo

关于 stackoverflow 有几个相关的问题，但要么我的情况不同，要么我太笨，无法将这些与情况联系起来。我希望有人可以帮助我解决这个问题。此外，我什至不是 .NET 开发人员，因此对于任何错误的术语使用，我提前道歉。

我的场景如下： 用于部署我们的 .net 应用程序（One Click？）的工具将其放在全名超过 300 个字符的目录中。该应用程序使用第三方组件——我们称之为 dbstore——处理驻留在应用程序部署目录中的指定文件。

到目前为止，我们正在使用Assembly.GetExecutingAssembly().GetName().CodeBase构建要传递给 dbstore 的文件的完全限定名。但是 dbstore 使用旧式 API 并在尝试打开文件时失败。

由于 dbstore 预计不会很快更改，因此建议将应用程序 chdir 到部署目录并将当前目录中的相对路径名传递给它。这也是C# 代码中接受的响应 PathTooLongException 中描述的方法

但是我发现Directory.SetCurrentDirectory也会抛出PathTooLongException. 即使我使用 UNC 路径名（例如以\\?\0000000000000\...

我在做一些根本错误的事情吗？还有其他功能可以使用吗？

编辑：似乎没有办法实现我正在寻找的东西。据我所知，没有办法将当前目录设置为长路径。

我在安装 Visual Studion 2010 扩展时遇到问题：

安装错误：System.IO.PathTooLongException: C:\Users\felix.DOMAIN\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Vendor\Vendor 2011 Developer Tools\1.0\ProjectTemplates\CSharp\XYZ\1033\Vendor.XyzDeveloperTools .XyzPackageProject.zip

我通过双击 .vsix 文件来安装扩展；所以我没有选择将 Vendor 2011 Developer Tools 缩短为 VendorTools。有没有其他（更手动）的方式来安装扩展？

顺便说一下，总长度是199个字符；我认为它小于 248 个字符的限制。如果有区别，我会使用 Win7 64 位

所以我正在编写一个程序来扫描计算机上的重复文件，因为我看到的程序非常慢，和/或内存占用，但是PathTooLongException当我尝试整个驱动器时我遇到了。在阅读了 C# 代码中的 PathTooLongException之后，我对以下两个问题感到好奇。

1. 如果每次更改级别时都切换当前目录会影响我的表现吗？

2. 有没有更好的方法来获取所有文件的目录结构（也许通过调用 tree.exe 之类的东西然后解析它）？

我在 50% 的 WinXP SP3 机器上遇到了这个异常。我知道大约 260 个字符的路径长度限制，但是可以做什么？

我已经将文件命名为只有 2 个字符，没有任何子目录，但是在一半的 WinXP 机器上，IsolatedStorage 的路径已经超过 260 个字符。

我在 .Net 4.0 中使用 DirectoryInfo 和 FileInfo 来枚举目录树中的文件，我遇到了 PathTooLongException。简化版如下

抛出错误时，我想知道是什么文件路径导致了问题。显然我不能要求，FullName因为那是错误的。我可以从中获取名称file.Name，但是如果我无法获取路径的其余部分，即使从 中找到该文件也可以正常工作file.Directory！（我不能使用它，因为实际代码要复杂得多）。PathTooLongExceptionDirectoryInfo

查看堆栈跟踪，它似乎正在使用内部路径（我看到一个受保护file.FullPath的调试），并试图从完整（超大）路径中删除目录。大多数问题似乎都涉及System.IO.Path.NormalizePath，我听说在 .Net 4.0 中经历了一些变化。我没有尝试过以前版本的框架。

我的问题：

1. 我怎样才能从这个异常中得到完整的路径；它似乎在没有任何有用信息的情况下通过了。
2. 为什么框架需要限制路径中的字符来截断文件名？

在此先感谢您的帮助，
安迪

我无法复制某些文件夹 260+ 个字符（例如：F:\NNNNNNNNNNNNNNNN\NNNNNNNNNN\ROOT\$RECYCLE.BIN\S-1-5-21-3299053755-4209892151-505108915-1000\$RMSL3U8\NNNNNNNNN NNNNNNNN\ NNNNNNNNNNN\NNNNNNNNNN\NNNNNNNNNN\publish\Application Files\TNNNNNNNNNNNN_1_0_0_0\NNNNNNNNNNNN.exe.manifest) 使用标准 DrectoryInfo.Create(); 添加 \?\ 或 \?\UNC\（如“\\?\UNC\”）只会引发另一个 ArgumentException。我究竟做错了什么？如果不使用 Directory.SetCurrentDirectory() 我还能做什么？

我的开源软件将远程文件夹同步到本地桌面。远程文件夹可以在 Alfresco 上，其中路径长度没有限制 ( /root/very/very/very/long/name.txt)。

在开发我使用的应用程序时System.IO.File.OpenWrite和System.IO.Stream.Write，但似乎它们不支持超过几百个字符的路径，因此用户报告错误，例如PathTooLongException使用长路径时。

必须绝对避免使用UNC路径，因为它们会导致与某些应用程序不兼容。

在这种情况下应该使用什么库/代码？

它必须是开源 C#。

I am running into an issue that a long URL will throw a System.IO.PathTooLongException. This is somewhat strange because a System.IO.PathTooLongException is actually for physical files, it is not related to URL's.

As an example, I have a URL that looks like the following :

Basically with the search terms bloating out the URL. We also allow a keyword search which can get kinda big if the user is looking for something specific. As a side note, the .mvc on the URL is a hangover of the application from when it ran on IIS6 and extensionless URL's were not supported, but it shouldn't really be an issue here.

What I believe the issue is, is that it looks for a physical file using the URL. I could be wrong, but I think that is the issue. Almost every article about PathTooLongException's revolve around actual files, not URL's being too long.

I had an inkling that within the IIS handler mappings, I could switch off to check if a physical file exists (I think this was a setting in IIS6?), but in IIS7 under request restrictions of a handler mapping, it only has "Invoke handler only if request is mapped to" and then file/folder/file or folder. This is NOT ticked for .mvc in IIS, and there is no where else that I have found to try and say "please don't look for a physical file if using this extension".

I could be way off base with my guesses on how to fix the issue.