为什么Path.GetDirectoryName函数必须取决于260个字符的限制 [英] Why Path.GetDirectoryName function has to be dependent on 260 chars limit
问题描述
public static void Main()
{
// testing file name
var fileName =
"\\\\server7\\EmailAttachments\\myfolder\\abc\\2012\\1126\\e85c6b82-edc5-4ce1-9ad0-8025b92d0105-o.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012=6f54a59ce903eeaff197f82937de4012.dom=38c55279fe168c290fb2b06a312b5d88&b=6f54a59ce903eeaff197f82937de4012";
var directory = fileName.GetDirectory();
}
public static string GetDirectory(this string fullyQualifiedFileName)
{
return Path.GetDirectoryName(fullyQualifiedFileName); // throwing exception here
}
获得例外
发生System.IO.PathTooLongException HResult = -2147024690
Message =指定的路径，文件名或两者都太长.充分限定的文件名必须少于260个字符，并且目录名称必须少于248个字符.来源= mscorlib
堆栈跟踪:在System.IO.Path.NormalizePath(字符串路径，布尔fullCheck，Int32 maxPathLength，布尔expandShortPaths)在System.IO.Path.GetDirectoryName(字符串路径)在f:\ Practice中的Sameer.FilePathExtension.GetDirectory(String fullyQualifiedFileName)中Projects \ Sameer \ Sameer \ FilePathExtension.cs:第137行InnerException:
System.IO.PathTooLongException occurred HResult=-2147024690
Message=The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. Source=mscorlib
StackTrace: at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) at System.IO.Path.GetDirectoryName(String path) at Sameer.FilePathExtension.GetDirectory(String fullyQualifiedFileName) in f:\Practice Projects\Sameer\Sameer\FilePathExtension.cs:line 137 InnerException:
我想知道为什么 GetDirectoryName 必须依赖于路径或文件名字符限制.
I am wondering why GetDirectoryName has to be dependent on path or filename chars limit.
推荐答案
msdn网站中记录的
As documented in msdn website
完整路径不得超过260个字符，以保持兼容性Windows操作系统"
"Full paths must not exceed 260 characters to maintain compatibility with Windows operating systems"
http://msdn.microsoft.com/en-us/library/system.io.pathtoolongexception(v = vs.100).aspx
以及其背后的原因，请参见下面的链接.
and the reason behind it you can find here as documented in the below link.
另一个问题是暴露会导致行为不一致长途支持.带有\?\前缀的长路径可以在大多数情况下使用与文件相关的Windows API，但不是所有Windows API.为了例如LoadLibrary，它将模块映射到调用过程，如果文件名长于MAX_PATH，则失败.所以这意味着MoveFile将使您可以将DLL移动到这样的位置:其路径超过260个字符，但是当您尝试加载DLL，它将失败.整个Windows中都有类似的示例蜜蜂;存在一些变通方法，但是它们是根据具体情况而定的.
Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.
另一个被认为是痛苦因素的因素是与其他基于Windows的应用程序和Windows的兼容性外壳程序本身，仅适用于短于MAX_PATH的路径(注意简要描述了Vista shell试图软化此限制的情况以下).这意味着，如果.NET支持长路径，那么我们会让您创建您无法通过资源管理器或命令访问的文件迅速的.
Another factor, which is considered more of a pain factor, is compatibility with other Windows-based applications and the Windows shell itself, which only work with paths shorter than MAX_PATH (note that the Vista shell attempts to soften this limit, briefly described below). This means that if .NET supports long paths, then we’d let you create files that you couldn’t access via Explorer or the command prompt.
也就是说，我们意识到强制执行260个字符的限制不是合理的长期解决方案.我们的客户不会碰到这个问题经常发生，但是当他们这样做时，他们非常不便.可能的解决方法是P/调用WindowsAPI，并使用\?\前缀，但这将是大量的代码复制System.IO中的功能.所以要解决问题，客户经常求助于目录的大修组织，人为地缩短目录名称(并更新每个引用位置).
That said, we realize that enforcing the 260 character limit isn’t a reasonable long-term solution. Our customers don’t run into this problem very often, but when they do, they’re extremely inconvenienced. A possible workaround is P/Invoking to the Windows APIs and using the \?\ prefix, but it would be a huge amount of code to duplicate the functionality in System.IO. So to work around the problem, customers often resort to an overhaul of directory organization, artificially shortening directory names (and updating every referencing location).
