如何处理名称超过 259 个字符的文件? [英] How to deal with files with a name longer than 259 characters?

查看:194
本文介绍了如何处理名称超过 259 个字符的文件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个应用程序,它遍历某些目录中的每个文件并对这些文件执行一些操作.其中,我必须检索文件大小和修改此文件的日期.

I'm working on an application which walks through every file in some directories and does some actions with those files. Among others, I must retrieve the file size and the date when this file was modified.

某些文件全名(目录+文件名)太长,我无法使用.NET Framework FileInfo,限制为MAX_PATH(260 个字符).许多网络资源建议通过 P/Invoke 使用原生的 Win32 函数来访问名称过长的文件.

Some file full names (directory + file name) being too long, I couldn't use .NET Framework FileInfo, which is limited to MAX_PATH (260 characters). Many web sources advised to use native Win32 functions through P/Invoke to access the files whose names are too long.

目前,Win32 函数似乎出现了完全相同的问题.例如,对于 270 字节的路径,GetFileAttributesEx (kernel32.dll) 失败并显示 Win32 错误 3 ERROR_PATH_NOT_FOUND.

Currently, the exactly same problem seems to arise with Win32 functions. For example, GetFileAttributesEx (kernel32.dll) fails with Win32 error 3 ERROR_PATH_NOT_FOUND for the path of 270 bytes.

完全相同的文件可以从 Notepad2 成功打开并在 Windows 资源管理器中成功显示(但由于 259 个字符的限制¹,例如 Visual Studio 2010 无法打开它).

The very same file can successfully be opened from Notepad2 and successfully displayed with Windows Explorer (but Visual Studio 2010 for example fails to open it because of the 259 characters limit¹).

当文件路径长度为 270 个字符时,我该怎么做才能访问文件?

What can I do to be able to access a file when the file path is 270 characters long?

注意事项:

  • 删除或忽略文件路径长度超过 259 个字符的文件不是解决方案.

  • Removing or ignoring files with the file path length longer than 259 characters is not a solution.

我只是在寻找与 Unicode 兼容的解决方案.

I'm looking for Unicode-compatible solutions only.

该应用程序将在安装了 .NET Framework 4 的 Windows 2008/Vista 或更高版本下运行.

The application will run under Windows 2008/Vista or later with .NET Framework 4 installed.

¹ 令人惊讶的是,Microsoft Word 2007 失败了,在没有任何软驱的计算机上抱怨软盘太小",或者在有 4 GB 的计算机上抱怨RAM 内存不足"RAM 剩余,或者最后是防病毒软件 [...] 需要更新".至少有一天,他们会停止在 Microsoft Office 等关键产品中显示这种愚蠢而无意义的错误吗?

推荐答案

.NET 4.6.2 解决方案

使用 \?C:Verrrrrrrrrrrrry 长路径 语法,如此处.

.NET Core 解决方案

它之所以有效,是因为框架为您添加了长路径语法.

It just works because the framework adds the long path syntax for you.

Pre .NET 4.6.2 解决方案

还使用长路径语法和带有 P/Invoke 的 Win32 API 函数的 Unicode 版本.来自命名文件、路径和命名空间:

Also use the long path syntax and the Unicode version of the Win32 API function with P/Invoke. From Naming Files, Paths, and Namespaces:

Windows API 有许多函数,这些函数也有 Unicode 版本,以允许最大总路径长度为 32,767 个字符的扩展长度路径.此类路径由以反斜杠分隔的组件组成,每个组件最多为 GetVolumeInformation 函数的 lpMaximumComponentLength 参数中返回的值(该值通常为 255 个字符).要指定扩展长度的路径,请使用 \? 前缀.例如,\?D:very long path.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the \? prefix. For example, \?D:very long path.

阅读此 Microsoft 支持页面也可能很有趣.

Kim Hamilton 在 BCL 团队博客上的 .NET 中的长路径 列出了处理这些路径的一些问题,他声称这是 .NET 中仍然不直接支持这种语法的原因:

A very extensive explanation in Long Paths in .NET by Kim Hamilton at the BCL Team blog lists a few hitches in handling these paths which he claims are the reason this syntax is still not supported in .NET directly:

过去我们不愿意添加长路径的原因有很多,为什么我们仍然对此保持谨慎<...>.

There are several reasons we were reluctant to add long paths in the past, and why we’re still careful about it <...>.

<...>\? 前缀不仅支持长路径;它会导致路径通过 Windows API 以最少的修改传递到文件系统.结果是 \? 关闭了由 Windows API 执行的文件名规范化,包括删除尾随空格、扩展."和.."、将相对路径转换为完整路径等.<...>

<...> the \? prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that \? turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding ‘.’ and ‘..’, converting relative paths into full paths, and so on.<...>

<...>带有 \? 前缀的长路径可用于大多数 文件相关 Windows API,但不是所有 Windows API.例如,LoadLibrary<...>如果文件名长于 MAX_PATH,则失败.<...>在整个 Windows API 中都有类似的例子;存在一些变通方法,但它们要视具体情况而定.

<...> Long paths with the \? prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary<...> fails if the file name is longer than MAX_PATH. <...> There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

另一个因素<...>与其他基于 Windows 的应用程序和 Windows shell 本身兼容 <...>

Another factor <...> is compatibility with other Windows-based applications and the Windows shell itself <...>

因为这个问题变得越来越普遍<...>整个 Microsoft 都在努力解决这个问题.事实上,作为一个及时的 Vista 插件,您会注意到一些减少达到 MAX_PATH 限制的机会的变化:许多特殊的文件夹名称已经缩短,更有趣的是,shell 正在使用自动路径收缩功能<...>尝试将它们压缩为 260 个字符.

Because this problem is becoming increasingly common <...> there are efforts throughout Microsoft to address it. In fact, as a timely Vista plug, you’ll notice a couple of changes that reduce the chance of hitting the MAX_PATH limit: many of the special folder names have shortened and, more interestingly, the shell is using an auto-path shrinking feature <...> to attempt to squeeze them into 260 characters.


警告:您可能需要直接调用 Windows API,因为我认为 .NET Framework 可能不支持这种路径语法.


Warning: You might need to call the Windows APIs directly, since I think the .NET Framework might not support this kind of path syntax.

这篇关于如何处理名称超过 259 个字符的文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆