I am trying to uncompresss a bzip2 file (~55 GB) with the command tar -jxvf file.tar.bz2 However I found that the decompression process gets stuck at a certain file and, after waiting a long duration, gives the error message shown below without decompressing the other files.

bzip2: Compressed file ends unexpectedly;
        perhaps it is corrupted?  *Possible* reason follows.
bzip2: Inappropriate ioctl for device
        Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

The last file where decompression stucks happens to be tar file. Is it possible to bypass this tar file and continue to extract other files if I'm not interested in that tar file?

1 Answer 1


In general, if the compressed stream is corrupted at some point, you can't extract anything past this point.

It suggests to use bzip2recover. It is nice idea, but unfortunately blocks are of slightly different lengths in reality. That "900k by default" is an approximate and each block has slightly different length (try to compress a big file with bzip2, then bzip2recover it and then extract a few blocks to see that yourself).

To see which block was corrupted you can use bzip2 -tvv.

If you can figure out what was the uncompressed length of the corrupted block (for example, by reading surrounding surviving blocks and deducing how many bytes are missing between them), you can try to create zero-filled block of that length to replace corrupted block, then bzip2 it and feed the joined stream to tar stdin to extract (use bzip2 -dc rec*file.bz2 | tar -xapf -). Then, if there was no tar metadata in corrupted region, you'll get almost everything extracted (except that one file will contain a whole block of zeros).

If you can not figure out that length, you're completely out of luck. For some data (e.g. video) it could be acceptable to cut some bytes from the middle of the file and then expect it will recover; for tar it is not acceptable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .