带焦油的错误代码141

Question

tar -xvzf $ filename.tar.gz || {exit $？; }

这里我的脚本将以errorCode 141退出.我正在使用带有tar版本1.15的Fedora Core 6

它不会一直发生,但超过70%的时间失败.

Answer 1

我意识到这个帖子已经有几年了,但是我正在评论那些因错误而偶然发现这个帖子的人.

无论何时使用压缩选项,tar都会使用管道隐式打开与底层程序的连接.所以,在OP的例子中:tar -xvzf $filename.tar.gztar实际上会做的是运行类似的东西:gunzip $filename.tar.gz | tar -xv -.您可以通过运行a来验证这一点top,您将看到两个进程(一个用于tar,一个用于gzip).

有时候,管道本身会破裂.例如,如果文件不是gzip文件.以此为例: tar -xvzf somefile.iso,这相当于gunzip somefile.iso | tar -xv -.在这种情况下,gzip会出错.当gzip错误输出时,管道将中断.另一种可能性是如果gzip文件是正确的,但其中的tar文件已损坏.在这种情况下,gzip开始将未压缩的流发送到tar,但随后tar意识到出错了并关闭了流.gzip然后会出错,因为它的输出是关闭的.

在退出值中,大于128的值表示由于信号而终止,而大于128的值表示哪个信号导致终止.因此,如果我们从OP的退出代码141中减去128,我们得到13,这对应于SIGPIPE(man 7 signal对于标准信号列表及其对应的整数值).

该手册页将SIGPIPE的注释列为"Broken pipe:写入没有读者的管道".那么,似乎gzip正试图写入管道,但tar已停止监听.我的猜测是gzip成功解压缩文件,但未压缩的流不是有效的tar存档.我的建议是在文件上运行gunzip,然后在结果文件上运行tar并查看哪一个失败(基于SIGPIPE,我的猜测是tar会失败).在任何一种情况下,这些版本的工具看起来都不能读取该文件(腐败或某种版本冲突).

这些文件是如何制作的(tar有哪些选项等)？它们是在这台机器还是其他机器上创建的？如果您在此计算机上创建.tar.gz文件,同一台计算机是否可以在没有错误的情况下提取这些文件？

Answer 2

作为一种解决方法，我们现在使用 cpio 进行归档，这对我们来说效果很好，尽管我想知道为什么 tar 会导致这个问题，它已经存在很长时间了，并且多年来一直被用作标准工具。