Linux Tar 错误：存档中有意外的 EOF
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1325888/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Tar error: Unexpected EOF in archive
提问by
I tar a directory full of JPEG images:
我 tar 一个充满 JPEG 图像的目录：
tar cvfz myarchive.tar.gz mydirectory
When I untar the archive:
当我解压存档时：
tar xvfz myarchive.tar.gz
I get an error:
我收到一个错误：
tar: Unexpected EOF in archive
Looking at the output, it fails in the middle of one particular JPEG image.
查看输出，它在一个特定 JPEG 图像的中间失败。
What am I doing wrong?
我究竟做错了什么？
采纳答案by paxdiablo
Interesting. I have a few questions which may point out the problem.
有趣的。我有几个问题可以指出问题所在。
1/ Are you untarring on the same platform as you're tarring on? They may be different versions of tar(e.g., GNU and old-unix)? If they're different, can you untar on the same box you tarred on?
1/ 你是否在同一个平台上解压？它们可能是不同版本的tar（例如，GNU 和 old-unix）？如果它们不同，你能在你涂上柏油的同一个盒子上解开吗？
2/ What happens when you simply gunzip myarchive.tar.gz? Does that work? Maybe your file is being corrupted/truncated. I'm assuming you would notice if the compression generated errors, yes?
2/ 当你简单地 gunzip myarchive.tar.gz 时会发生什么？那样有用吗？也许您的文件已损坏/截断。我假设您会注意到压缩是否会产生错误，是吗？
Based on the GNU tar source, it will only print that message if find_next_block()returns 0 prematurely which is usually caused by truncated archive.
基于 GNU tar 源，它只会在find_next_block()过早返回 0 时打印该消息，这通常是由截断的存档引起的。
回答by Saradhi
May be you have ftped the file in ascii mode instead of binary mode ? If not, this might help.
可能您以 ascii 模式而不是二进制模式 ftped 文件？如果没有，这可能会有所帮助。
$gunzip myarchive.tar.gz
$gunzip myarchive.tar.gz
And then untar the resulting tar file using
然后使用解压生成的 tar 文件
$tar xvf myarchive.tar
$tar xvf myarchive.tar
Hope this helps.
希望这可以帮助。
回答by Jerome
I had a similar problem with truncated tar files being produced by a cron job and redirecting standard out to a file fixed the issue.
我有一个类似的问题，即由 cron 作业生成截断的 tar 文件并将标准重定向到文件修复了该问题。
From talking to a colleague, cron creates a pipe and limits the amount of output that can be sent to standard out. I fixed mine by removing -v from my tar command, making it much less verbose and keeping the error output in the same spot as the rest of my cron jobs. If you need the verbose tar output, you'll need to redirect to a file, though.
通过与同事交谈，cron 创建了一个管道并限制了可以发送到标准输出的输出量。我通过从我的 tar 命令中删除 -v 来修复我的问题，使其不那么冗长，并将错误输出与我的其他 cron 作业保持在同一位置。但是，如果您需要详细的 tar 输出，则需要重定向到一个文件。
回答by KawaiKx
In my case, I had started untar before the uploading of the tar file was complete.
就我而言，我在 tar 文件上传完成之前就开始解压缩了。
回答by user379462
I had a similar error, but in my case the cause was file renaming. I was creating a gzipped file file1.tar.gzand repeatedly updating it in another tarfile with tar -uvf ./combined.tar ./file1.tar.gz. I got the unexpected EOF error when after untarring combined.tarand trying to untar file1.tar.gz.
我有一个类似的错误，但就我而言，原因是文件重命名。我正在创建一个 gzip 文件，file1.tar.gz并在另一个 tarfile 中使用tar -uvf ./combined.tar ./file1.tar.gz. 在解压combined.tar并尝试解压后，我收到了意外的 EOF 错误file1.tar.gz。
I noticed there was a difference in the output of filebefore and after tarring:
我注意到file在tarring之前和之后的输出存在差异：
$file file1.tar.gz
file1.tar.gz: gzip compressed data, was "file1.tar", last modified: Mon Jul 29 12:00:00 2019, from Unix
$tar xvf combined.tar
$file file1.tar.gz
file1.tar.gz: gzip compressed data, was "file_old.tar", last modified: Mon Jul 29 12:00:00 2019, from Unix
So, it appears that the file had a different name when I originally created combined.tar, and using the tar update function doesn't overwrite the metadata for the gzipped filename. The solution was to recreate combined.tarfrom scratch instead of updating it.
因此，看起来文件在我最初创建时具有不同的名称combined.tar，并且使用 tar 更新功能不会覆盖 gzipped 文件名的元数据。解决方案是combined.tar从头开始重新创建而不是更新它。
I still don't know exactly what happened, since changing the name of a gzipped file doesn't normally break it.
我仍然不知道到底发生了什么，因为更改 gzip 文件的名称通常不会破坏它。
