『壹』 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:盘根目录下,然后再压缩