bz2 file and "This does not look like a tar archive"

Question

I've seen other questions related to this error (like Extracting a tar.gz file returns, “This does not look like a tar archive.”), but I'm not sure how to apply them to my problem:

First, download file:

$ wget --no-check-certificate https://wxpython.org/Phoenix/tools/doxygen-1.8.8-linux.bz2
--2017-04-06 15:06:11--  https://wxpython.org/Phoenix/tools/doxygen-1.8.8-linux.bz2
Resolving wxpython.org (wxpython.org)... 85.234.150.54
Connecting to wxpython.org (wxpython.org)|85.234.150.54|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3961996 (3.8M) [application/x-bzip2]
Saving to: ‘doxygen-1.8.8-linux.bz2’

100%[==============================================================================>] 3,961,996    734KB/s   in 5.0s   

2017-04-06 15:06:16 (778 KB/s) - ‘doxygen-1.8.8-linux.bz2’ saved [3961996/3961996]

Then, check file type of file:

$ file doxygen-1.8.8-linux.bz2 
doxygen-1.8.8-linux.bz2: bzip2 compressed data, block size = 900k

Well, it's "bzip2 compressed data", let's unpack it?:

$ tar xjvf doxygen-1.8.8-linux.bz2
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains ‘\351\357\377I\211\304H\211’ where numeric mode_t value expected
tar: Archive contains ‘A\270\001\0\0\0H\211ǹ\001’ where numeric time_t value expected
tar: Archive contains ‘\307\350\216v)\0I\307’ where numeric uid_t value expected
tar: Archive contains ‘\004$P\254|\0\2770’ where numeric gid_t value expected
@\2678\350\330\351\357\377\2778
tar: @\2678\350\330\351\357\377\2778: Unknown file type '', extracted as normal file
tar: @�8������8: implausibly old time stamp 1970-01-01 00:59:59
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

And I get an empty file unpacked:

$ ls -la @�8������8 
-rwxrwxr-x 1 user user 0 Jan  1  1970 @?8??????8

Strangely, if I use file-roller (Archive Manager) and unpack from the GUI, I do get a file unpacked:

$ ls -la ~/Desktop/doxygen-1.8.8-linux 
-rw-rw-r-- 1 user user 12283548 Apr  6 15:13 /home/user/Desktop/doxygen-1.8.8-linux
$ file ~/Desktop/doxygen-1.8.8-linux 
/home/user/Desktop/doxygen-1.8.8-linux: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0eccee11d38322d5df3a1723651c2f18303e1188, not stripped

Ok, so what is going on here - why can't I unpack this from the command line, and how can I unpack this using the command line?

---

EDIT: actually I can unpack it with:

$ bzip2 -d doxygen-1.8.8-linux.bz2 
$ file doxygen-1.8.8-linux 
doxygen-1.8.8-linux: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0eccee11d38322d5df3a1723651c2f18303e1188, not stripped

... so the only question remaining is - why couldn't I have used tar for this, as I had always otherwise done?

Answer 1

tar is just copying files together to one big .tar file without compression. bzip2, gzip, xz are file compressors for single files ie. tar files. The extension is .tar.gz, .tar.xz, .tar.bz2 or .tbz(2), .txz, .tgz etc.

tar can only handle .tar files with or without compression with bzip2, xz, gzip. but not non tar'ed .bz2, .xz archives.

Non tar'ed bzip files can be extracted with bzip2 -d file.bz2.

Answer 2

The reason your file "does not look like a tar archive" is because it isn't a tar archive, but just a single bzip2-compressed executable file. You can tell this from the file command output, as well as from the fact that your file doesn't have a .tar.bz2 filename extension, but just .bz2 (although, of course, one can technically rename any file to have any extension).

Think of tar and bzip2 as separate layers with different purposes: tar combines a bunch of different files into a single big file, while bzip2 compresses a file (often, the output of tar) containing repetitive data by encoding the repetitive parts in a more compact way.

Tar is often used together with bzip2 (or gzip or other similar file compression programs) for two main reasons:

1. Tar archives are excellent candidates for bzip2 compression, since they often contain lots of repetitive data, and since it's often desirable to squeeze them as small as possible to save space.

   Also, as the name suggests, tar archives are typically used for archiving data which is not expected to be accessed or modified frequently. Thus, the fact that bzip2 compression and decompression make accessing and modifying the content slower is not a particularly major issue with them.

2. By design, bzip2 (and gzip, etc.) cannot compress more than one file at a time. If you want to make a single bzip2 compressed archive containing multiple files, you need to first tar the files together.

   This design is part of the Unix philosophy of making tools that each do one job, and do it well. Tar joins files together. Bzip2 compresses files. One advantage of this modular design, compared to other popular compression tools like zip that are designed to both at the same time, is that each part is easily replaceable without affecting the other. For example, bzip2 is an (in some ways) improved drop-in replacement for gzip, which in turn is a drop-in replacement for the older compress program. All of them, and any other even better file compression programs (such as xz) that exist now or in the future, can be used to compress the same tar archives.

Because tar and xz / bzip2 / gzip / compress are so often used together, many common tar implementations (including the GNU tar typically used on Linux) provide some extra convenience features for working with compressed archives. In particular, they can be told (via command-line switches) to automatically compress their packed output using one of these compression programs, and they may be able to detect archives that have been thus compressed and automatically decompress them before unpacking. However, these features exist just for user convenience: the exact same results can be achieved simply by piping the input/output of tar through bzip2 or some other file compressor.

---

However, sometimes you do want to use either of tar or bzip2 alone, without the other. Notably, if you only have a single large file that you wish to compress, then you really don't need the extra overhead of tarring it first — it's more efficient to just apply bzip2 directly to the original file. This is what you seem to have: a single large bzip2-compressed file.

If you try to feed this file to tar, it will first correctly detect that it's bzip2-compressed, and try to decompress it before processing it further. But since you're explicitly calling tar, it expects to actually receive a (possibly compressed) tar archive, and when it doesn't find what it expects after uncompressing the input, it gives the error message that you saw.

Instead, as Michael D. has already noted in the comments, you can decompress this file using bzip2 directly, with:

bzip2 -d doxygen-1.8.8-linux.bz2

or (equivalently):

bunzip2 doxygen-1.8.8-linux.bz2

By default, when b(un)zip2 is invoked like this, the decompressed file will have the same name as the original, minus the .bz2 extension. After successful decompression, the original compressed file will be automatically deleted. (If you don't want that, pass the -k or --keep option to b(un)zip2.) Of course, you can also recompress the uncompressed file with:

bzip2 doxygen-1.8.8-linux

Alternatively, you can simply pass data into b(un)zip2 over stdin, and receive the corresponding (un)compressed data via stdout, like this:

bunzip2 < doxygen-1.8.8-linux.bz2 > doxygen-1.8.8-linux-or-whatever

This does the same thing as the earlier bunzip2 command above, except that it won't (and can't) automatically delete the input file, and that you can give the output file any name you want.

More usefully, you can also pipe the input and/or the output of b(un)zip2 to/from another program. For example, instead of first downloading the compressed file to disk with wget and then decompressing it, you could just pipe the output of wget directly into bunzip2:

wget --output-document=- \
  https://wxpython.org/Phoenix/tools/doxygen-1.8.8-linux.bz2 \
  | bunzip2 > doxygen-1.8.8-linux

The --output-document=- switch (which could be abbreviated to -O -) tells wget to write the downloaded data to stdout instead of saving it to disk. The last line then pipes to output of wget into bunzip2, and directs the output of bunzip2 into the file doxygen-1.8.8-linux. The backslashes just mark places where I've split the command onto multiple lines for readability; the shell will ignore them and the line breaks that follow them.