我正在开发一个应用程序,它遍历某些目录中的每个文件,并对这些文件执行一些操作.其中,我必须检索文件大小和修改此文件的日期.
有些文件全名(目录+文件名)太长,我无法使用.NET Framework FileInfo,限制为MAX_PATH(260个字符).许多Web资源建议通过P/Invoke使用本机Win32函数来访问名称太长的文件.
目前,Win32函数似乎出现了完全相同的问题.例如,对于GetFileAttributesEx270字节的路径,(kernel32.dll)失败,Win32错误3 ERROR_PATH_NOT_FOUND.
可以从Notepad2成功打开同一个文件并使用Windows资源管理器成功显示(但Visual Studio 2010例如由于259个字符限制¹而无法打开它).
当文件路径长度为270个字符时,如何才能访问文件？
笔记:
删除或忽略文件路径长度超过259个字符的文件不是解决方案.
我正在寻找仅与Unicode兼容的解决方案.
该应用程序将在安装了.NET Framework 4的Windows 2008/Vista或更高版本下运行.
¹令人惊讶的是,Microsoft Word 2007失败了,在没有任何软盘驱动器的计算机上抱怨"软盘太小",或者在剩下4 GB RAM时"RAM内存很低",或者最后那个"防病毒软件[...]需要更新".他们有一天会停止显示至少在像Microsoft Office这样的关键产品中出现如此愚蠢无意义的错误吗？
我目前正在研究一个遍历各种目录的程序,以确保使用特定文件File.Exists().
该应用程序声称某些文件实际上不存在,我最近发现此错误是由于路径太长.
我意识到有关SO的问题可以解决File.Exists()返回错误值的问题,但似乎没有解决这个特定问题.
重命名目录和文件以缩短路径实际上不是一个选项,所以我不知道该做什么.是否有解决此问题的解决方法？
使用中的代码没有什么特别之处(我已经删除了一些不相关的代码),但我会在下面包含它以防万一它有所帮助.
private void checkFile(string path)
{
if (!File.Exists(path))
Console.WriteLine(" * File: " + path + " does not exist.");
}
背景
我需要编写一个使用.NET 2.0版本的工具(由于政治,商业和机密性/信任原因,使用现成的东西不是这个客户的选项)通过网络将文件从一个服务器迁移到另一个服务器.服务器是本地团队的文件服务器,某些团队文件夹需要迁移到其他服务器以便于重组.基本的想法是我们读取每个文件并在数小时内通过网络流式传输,几天后数据将被迁移.需要保留文件权限.由于这将花费几天时间(我们正在谈论几千兆字节的数据,对于某些团队而言),我们需要每晚迭代文件并比较修改日期并更新已更改的日期.理论上说,最终新服务器将拥有最新的文件副本,用户可以切换到新服务器.它当然不是那么简单,但我们有一个我们认为应该工作的设计:)
问题
所以理论上我们只需打开文件,通过网络流式传输,然后在另一端写入,对吧？:)
不幸的是,在服务器本身,文件共享是在文件夹路径创建的,例如:
D:\ Data\Team Shares\DIVISION\DEPARTMENT\NAME OF TEAM - 可能会长期一直
对于每个用户,此路径将映射到驱动器,例如,它将作为\\ SERVER\TEAMNAME共享并映射到T:驱动器.
这导致了从T:驱动器可见的文件在MAX_PATH限制范围内的情况,但是当在服务器本身上本地查看时,它们会超出它.我们无法使用网络共享来访问文件,因为这个工具需要是通用的,要在数百个这样的服务器上运行,并且没有标准的方法来判断哪些文件共享是我们应该移动的文件共享和那些不是 - 甚至没有命名约定标准.此外,偶尔会有其他股份的子股票,因此我们超过MAX_PATH限额两倍!
我知道使用"\\？\"前缀指定路径的解决方法,该路径将路径视为UNC路径,并允许理论上最多32k个字符.
这种解决方法是在Win32 API级别实现的,System.IO命名空间(大部分)基本上只是本机Win32 API函数的一个薄包装,但是在将调用交给API之前,Microsoft已经"帮助"实现了额外(不正确)的验证. .在这种情况下,.NET Framework拒绝该路径,因为它声称'？' 是一个无效的路径字符.
所以我的问题是......有没有一种方法我没有想到这将允许我解决这个问题,而不必完全重写几乎整个System.IO命名空间,加载P/Invoke调用,只是为了删除这个烦人的验证？