爲什麼Path.GetDirectoryName函數是依賴於260個字符限制

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 
    }

獲取異常下面爲什麼Path.GetDirectoryName函數是依賴於260個字符限制

System.IO.PathTooLongException發生的HResult = -2147024690
消息=指定的路徑，文件名，或者兩者都過長。完整限定文件名必須少於260個字符，並且目錄名稱必須少於248個字符。源= mscorlib程序
堆棧跟蹤：在System.IO.Path.NormalizePath（字符串路徑，布爾fullCheck，的Int32 maxPathLength，布爾expandShortPaths）在System.IO.Path.GetDirectoryName（字符串路徑）在Sameer.FilePathExtension.GetDirectory（字符串fullyQualifiedFileName）在F：\實踐項目\薩米爾\薩米爾\ FilePathExtension.cs：137行的InnerException：

我很奇怪，爲什麼GetDirectoryName必須依賴路徑或文件名字符限制。

來源

2014-04-01 Sameer

從MSDN documentation：

最大路徑長度的限制

在Windows API（在以下段落中討論一些例外），對於路徑的最大長度爲MAX_PATH，這是定義爲260個字符。本地路徑的結構如下順序：驅動器號，冒號，反斜槓，由反斜槓分隔的名稱組件，以及終止空字符。例如，驅動器D上的最大路徑是「D：\某些256個字符的路徑字符串」其中「」表示當前系統代碼頁的不可見的終止空字符。（字符<>在這裏用於視覺清晰度，並且不能是有效的路徑串的一部分。）

來源

2014-04-01 08:57:46 Phylogenesis

如MSDN網站記錄

「全路徑必須不超過260個字符，以保持兼容性與Windows操作系統」

http://msdn.microsoft.com/en-us/library/system.io.pathtoolongexception(v=vs.100).aspx

及其背後的原因，你可以在這裏找到下面的鏈接中記錄。

另一個問題是暴露長路徑支持導致的行爲不一致。帶有\？\前綴的長路徑可用於與文件相關的Windows API的大多數，但不能用於所有的Windows API。例如，對於示例，如果文件名比MAX_PATH長，則將模塊映射到調用進程的地址的LoadLibrary失敗。所以這意味着MoveFile將讓你移動一個DLL的位置，使得其路徑是超過260個字符，但是當你試圖加載DLL ，它會失敗。在整個Windows API中都有類似的例子;有一些解決方法存在，但它們是基於個案的。

另一個因素，認爲這是一種痛苦的因素，是與其他基於Windows的應用程序和Windows 外殼本身，它只是比MAX_PATH較短的路徑工作（注意的是，Vista的外殼試圖軟化兼容性這個限制，下面簡要描述）。這意味着，如果.NET支持長的路徑，那麼我們會讓你創建，你可以不通過資源管理器或命令提示符訪問文件。

這就是說，我們認識到，執行的260個字符的限制不是一個合理的長期的解決方案。我們的客戶經常不會遇到這個問題，但是當他們這樣做時，他們極其不便。一個可能的解決方法是P /調用到Windows API和使用\？\前綴，但是這將是一個巨大的代碼量System.IO複製的功能。因此，要解決此問題，客戶往往求助於目錄組織的檢修，人爲地縮短目錄名（和更新每引用位置）。

http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

來源

2014-04-01 08:58:11 Neel

+1參考* *爲什麼它的工作原理是這樣的。即使這種推理看起來很奇怪，因爲底層文件系統都支持長路徑名。 – CodingIntrigue

我的問題是爲什麼Path.GetDirectoryName（文件名）必須依賴於限制。我認爲它只能是字符串操作，所以不應該依賴於限制。限制只能在保存文件時發揮作用。旁邊的** Path.GetFileName（fileName）完美**。 – Sameer

這只是一個驗證適用於輸入，所以輸出是一個有效的路徑。在使用返回的路徑來進一步調用文件系統的情況下，這是很有必要的。從技術上講，你不需要添加這個驗證，但如果它有益於你最常見的場景，這是一個很好的設計。除此之外，我懷疑這種方法使用通用內部代碼進行路徑分析，而不是僅爲此方法複製解析代碼。

來源

2014-04-01 09:02:52 ShitalShah

爲什麼Path.GetDirectoryName函數是依賴於260個字符限制

回答

相關問題