我有一个使用共享链接(非公共链接)和curl 从 Dropbox 下载的文件夹。它作为压缩文件夹下载。我需要在 bash shell 脚本中使用 unzip 来解压该文件夹。每当解压缩文件夹时,我都会收到以下错误:
warning: stripped absolute path spec from /
mapname: conversion of failed
为了确保这不是curl的奇怪问题,我直接从Dropbox下载了该文件夹并再次尝试。我遇到了同样的错误。所有的文件和子目录都出现了,而且它们的完整性似乎没有任何问题。使用 GUI 解压缩任一文件夹都不会出现错误消息。
我运行了 unzip -l 并注意到一个奇怪的第一个条目:
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
0 Defl:N 2 0% 01-23-14 19:38 00000000 /
我相信正是这个空目录导致了问题。我的问题是,有什么方法可以忽略这个空目录或抑制错误消息(我尝试了 -qq 但没有运气)?或者,我做错/遗漏了什么吗?
我已经在
Mac OSX 10.9.1
和 Ubuntu Linux (Version Unknown)
上进行了测试,结果相同。
编辑:我还用
jar xf
对其进行了测试,它工作正常,没有任何错误。运行 jar xvf
显示它 created: /
。我仍然认为是这个空的、未命名的目录导致了问题,但我似乎无法正确理解我的语法,以便解压缩会忽略它。我只想使用 jar,但我需要能够指定输出目录。
尝试从命令行解压 Dropbox 自动生成的 zip,我也发现了这条消息:
warning: stripped absolute path spec from /
mapname: conversion of failed
我将 Dropbox 的 zip 与普通 zip 进行了比较。
不同之处在于,解压时,Dropbox 中的第一个位置会出现类似
/
的文件。
我只是将选项
-x /
添加到解压缩命令中尝试排除它,它对我有用。
在我看来,根本问题是存档,而不是你的命令。
默认情况下,我们将相对路径存储在 ZIP 文件中。示例:
$ zip tmp.zip /home/mcoolive/*txt
adding: home/mcoolive/file1.txt (deflated 73%)
adding: home/mcoolive/file2.txt (deflated 76%)
默认情况下,解压缩会重新创建所有文件,并在当前目录中重新创建子目录。
在您的情况下,存档包含绝对路径。这是邪恶的。因此,您的客户端将绝对路径转换为相对路径,并发出警告。
我只是想引起人们对某事的注意。 至少在我的例子中,使用“-x /”实际上使警报消失了,但有些文件没有被提取。