One tarball, eight different extractions: the archive that breaks every tar tool

The Hardest Tarball?

A single GNU tar invocation produces an archive that unpacks in eight distinct ways depending on the tool. By giving a hard link a 512-byte size via a pax header, the author pits GNU tar, bsdtar, 7-Zip, Java, PHP, Ruby, R, and Haskell against each other, with results ranging from missing files to a 512-null-byte file. It is one of 134 tricky tarballs in the tar-minefield test suite.

This archive gives by far the richest and most surprising results I've encountered so far when extracting it with well-known tar utilities and libraries.
  1. Joker_vD

    > Now, POSIX says that data blocks for a hard link “may be included” in pax archives, but the implications of this are not entirely clear.

    How so? If the data blocks are included, then those are the intended content of the file behind that hard link. They should overwrite the previous content of the file.

    > So the 512 bytes after the hard link are its data, and not the header of empty as we archived it?

    Yes, precisely.

    > How can a hard link have different contents from its previous counterpart file?

    Why, very simply: while the archive was being created, the file behind the two different hard links changed; the archival utility noticed it, and included the new content of the file as the content for the second hard link instead of rewinding and overwriting the original file in the archive (which would be impossible to do on a tape, you know). At least I believe that's what was the rationale for this allowance, and the intended behavior on the extraction.

  2. JdeBP

    There's a prominent tar implementation missing. paxmirabilis is tar, cpio, and pax all in one, as a multiple-call binary. It's what one gets as pax in Debian, in fact.

    * https://mbsd.evolvis.org/pax.htm

    * https://manpages.debian.org/trixie/pax/index.html

    No, it's not libarchive's bsdtar. There's more than 1 tar in the BSD world.

  3. bartvk

    This guy, what a hero. He even included a little graphic to show how this "hardest tarball" looks like.

    At the bottom, there's a link to much more edge cases.

    It reminds me of this beauty: "Parsing JSON is a Minefield"

    https://news.ycombinator.com/item?id=16897061

  4. molticrystal

    >NET, Julia and uv's tar-codec - These implementations reject the tarball. I believe this is the best thing you can do, even if it's technically not POSIX-compliant.

    While this is the safest choice, it is the least helpful, I would always prefer to get something out of an archive then nothing. Damage/irregularity to an archive shouldn't prevent data inspection, just a warning and a way to fall back with caveats for what can be extracted.

  5. zahlman

    > This tarball is one of 134 tricky tarballs that I'm collecting and categorizing in my test suite haampie/tar-minefield

    Surely "tarpit" is a more natural name?

More from this day

2026-11-10