文件名長度超過260

『壹』 rar文件名太長無法解壓

rar文件名太長無法解壓，是設置錯誤造成的，解決方法如下：

1、首先准備好WinRAR，定位到要刪除文件的上一層目錄。

『貳』 windows 文件名太長怎麼辦

1.
windows7顯示文件名太長可以右鍵單擊，選擇重命名，命名一個短的文件名；
2.
或者回右鍵單擊選擇隱藏拓答展名也可以使文件名顯示短些。
3.
文件名，為文件指定的名稱。為了區分不同的文件，必須給每個文件命名，計算機對文件實行按名存取的操作方式。

『叄』 文件名的最大長度是多少

在windows下面,單個文件名的長度限制是255,完整的路徑長度(如E:\test\aaa.txt這樣限制是260)

在XP、2003和win7上最大長度一樣專。
注意的是，由於DOS下僅僅屬支持8.3格式，所以如果在dos下查看，會顯示不全的。

『肆』 如何建立路徑長度超過260字元的文件夾

讓我們從BCL中的一個有趣的異常開始今天的話題:[PathTooLongException]: 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.我們的客戶在bug報告里說: 「路徑最多隻有260個字元? MS搞笑的吧. 把這個限制搞得更長一些!」. 在這里我將會對這些提交bug報告的人(很抱歉你們的bug被關成了」won』t fix」)詳細解釋這個問題並告訴你們我們對此所作出的努力.讓我們先來澄清一些術語:Path: 一個文件的全路徑. 比如你又一個文件: c:\temp\fileA.txt, 那麼通常你會叫這個文件fileA.txt, 但它的全路徑應該是c:\temp\fileA.txt.
MAX_PATH: Windows API定義的路徑的最大長度, 260個字元.
Long path: 一個長度超過了MAX_PATH的路徑.
Long file name: 跟long path還不一樣. 這個其實是用來跟短文件名作對比的, 就是以前我們說的那個8.3格式的文件名.
眾所周知.NET API是依賴於Windows API的, 從這一點上看, 上面的這個異常就沒有什麼問題了. 然而Windows API還提供了一個方法來繞過這個MAX_PATH的限制. 如果你在你的文件路徑前面加上」\\?\」的前綴, 然後調用unicode版本的Windows API, 那麼你的path的最大長度就可以達到32k了. 也就是說你只要加上前綴」\\?\」就可以在Windows API中使用long path了.沒有人會抱怨32k的長度限制了, 那麼是不是就可以說問題解決了呢? 也不完全是. 過去我們不願意支持long path是有原因的, 而且現在我們還會考慮這些原因. 第一個原因就是安全. 前綴」\\?\」並不僅僅是打破的long path的限制, 它還能讓path在到達文件系統之前只受到Windows API的最小的修正. 這樣做的結果就是」\\?\」規避了Windows API對於path的一系列的標准化的操作: 去掉path後面的空格, 把』.』和』..』擴展為相應的內容, 以及把相對路徑轉換成全路徑等等. 在.Net中的如果用FileIOPermission attribute來保證安全, 我們就不得不使用標准化後的路徑. 而不用FileIOPermission就會有安全隱患. 現在我們明白了如果我們用前綴」\\?\」來解決long path的問題的話, 我們就必須能像Windows API那樣把路徑標准化.第二個原因是支持long path可能導致的不一致行為. 很多操作文件的Windows API都支持以」\\?\」 作為前綴的long path, 但僅僅是很多而不是全部. 比如LoadLibrary, 它的功能是將一個mole映射到調用者的地址空間, 在文件路徑超過MAX_PATH的時候就會失敗. 這就意味著你可以調用MoveFile把一個DLL放到一個路徑長度超過MAX_PATH的地方, 但是當你想載入這個DLL的時候卻失敗了. 在Windows API裡面有很多這樣的例子, 雖然有一些權宜之計, 但都是針對特殊問題的, 沒有一個通用的解決方案.另外一個因素, 也是最痛苦的一個, 是Windows Application和Windows shell本身在long path上的兼容性. 因為Windows shell本身只支持長度小於260的路徑 (下面會講到Vista shell弱化了這個限制). 就是說如果.NET支持了long path, 那麼你就可以通過你的.NET App創建一些在Explorer或是命令行中不能訪問的文件了. J我們已經意識到了260個字元的限制並不是很合理. 我們的客戶並不經常碰到這個問題, 但是一旦需要一個超出MAX_PATH的路徑, 就會覺得很不方便. 一個權宜之計是P/Invoking Windows API並使用」\\?\」前綴, 但是這樣就不得不寫一大坨跟System.IO重復的code. 所以為了解決這個問題, 我們的客戶常常會重新設計目錄結構, 絞盡腦汁的縮短目錄名. 因為這個問題已經逐漸變得普遍, 所以無論是.NET framework還是別的領域, MS都已經開始著手解決這個問題. 實際上在vista中你應該已經可以看到我們為了減少出現MAX_PATH的問題的幾率所作出的改動: 很多特定的目錄名已經被縮短 (譯注: \Documents and Settings à \Users, 實際上, 在MS有一個專門的alias叫longpath來談論這個問題), shell還有一個auto-path shrinking的功能, 它會用比較短的別名來表示路徑以把那些long path壓縮在260個字元以內.

『伍』 我壓縮文件是怎麼顯示文件名總長度必須不能超過260字元怎麼辦

windows 系統API顯示創建哪搜拿虧目李敏歷錄不能超過260個字元，你可以把文件拷貝到D:盤根目錄下，然後再壓縮