"tar \ gzip -n“和"tar”之间有什么区别吗？
我正在维护一些旧的脚本，我偶然发现：
tar -cvf - ${files} | gzip -n -c | openssl ...在没有gzip的"-n“的情况下，这和更紧凑的产品有什么实际的区别吗？在-n命令中，还有其他方法将“tar”传递给gzip吗？
tar -cvzf - ${files} | openssl ...这在Linux3.0.101-0.47.71上是默认的。我希望性能略有提高，但我担心的是不会导致下游的变化。
回答 2
Stack Overflow用户
发布于 2016-12-20 00:12:04
旧tar没有内置gzip压缩。在我所知道的任何gzip上，n通过stdin喂养都没有任何意义。当然，除了将gzip数据中的压缩时间戳设置为0之外。
老实说，我怀疑这种选择是否有用--在我所能测试的任何东西上，尺寸都保持不变。这是正确的行为--标头(如RFC 1952，Sec。2.2中所指定的)仅在几秒钟内有一个4B的时间--如果您将它设置为0，它就意味着“没有保存timespec”。因此，除非您不需要让gzip‘’ed数据的接收方知道它何时被压缩，否则-n没有好处。(如果您有一些基于未知时间的身份验证方案，则省略这种时间戳可能会带来安全好处，例如。会话ID是从启动设备后生成的，但坦率地说，我更愿意考虑插入这些安全漏洞，而不是将时间戳设置为零。)
Stack Overflow用户
发布于 2016-12-20 05:56:02
结果可能会有很大的不同。至少对于我使用的tar (macOS上的默认tar )。tar在写入stdout时以块形式写入所有输出，填充零以完成最后一个块，甚至在压缩后填充压缩后的数据。这是在手册页中记录的，所以它不是一个bug。默认的块大小是10K。使用默认的阻塞因子，tar -cvzf的结果几乎总是比tar -cvf ... | gzip大，平均为5K。
从手册页：
All archive output is written in correctly-sized blocks, even if the out-
put is being compressed. Whether or not the last output block is padded
to a full block size varies depending on the format and the output
device. For tar and cpio formats, the last block of output is padded to
a full block size if the output is being written to standard output or to
a character or block device such as a tape drive. If the output is being
written to a regular file, the last block will not be padded. Many com-
pressors, including gzip(1) and bzip2(1), complain about the null padding
when decompressing an archive created by tar, although they still extract
it correctly.我使用的是bsdtar 2.8.3。
GNU tar 1.29没有这样做，尽管文档似乎表明它应该：
If the output goes directly to a local disk, and not through stdout,
then the last write is not extended to a full record size. Otherwise,
reblocking occurs.文档还注意到了gzip抱怨尾随零的相同问题。然而，在通过stdout时，没有尾随的零。
https://stackoverflow.com/questions/41232995
复制相似问题
腾讯云开发者
