Ein einziges Tarball, acht verschiedene Entpackungen

The Hardest Tarball?

Ein mit einem einzigen GNU-tar-Aufruf erzeugtes Archiv entpackt sich je nach Tool völlig unterschiedlich: GNU tar, BusyBox, Python, Go und Perl ignorieren die Größe des Hardlinks; bsdtar schreibt 512 Bytes in den Hardlink; 7-Zip, node-tar, tar-fs und Rusts tar überspringen die Daten; Java Commons Compress erzeugt eine separate Datei; PHP PharData macht café leer; RubyGems extrahiert café gar nicht, sondern legt ein PaxHeaders-Verzeichnis an; R wendet die Größe fälschlich auf empty an; Haskell hat Probleme mit der UTF-8-Dekodierung; .NET, Julia und uv lehnen das Archiv ab. Der Autor sammelt 134 solcher kniffligen Tarballs in seiner Testsuite tar-minefield.

Ich glaube, das ist das Beste, was man tun kann, auch wenn es technisch nicht POSIX-konform ist.
  1. Joker_vD

    > Nun, POSIX sagt, dass Datenblöcke für einen Hardlink „enthalten sein können“ in pax-Archiven, aber die Implikationen davon sind nicht ganz klar.

    Wieso? Wenn die Datenblöcke enthalten sind, dann sind das der beabsichtigte Inhalt der Datei hinter diesem Hardlink. Sie sollten den vorherigen Inhalt der Datei überschreiben.

    > Also sind die 512 Bytes nach dem Hardlink seine Daten und nicht der Header von empty, wie wir es archiviert haben?

    Ja, genau.

    > Wie kann ein Hardlink einen anderen Inhalt haben als seine vorherige Gegenstückdatei?

    Nun, ganz einfach: Während das Archiv erstellt wurde, änderte sich die Datei hinter den beiden verschiedenen Hardlinks; das Archivierungsprogramm bemerkte dies und fügte den neuen Inhalt der Datei als Inhalt für den zweiten Hardlink ein, anstatt zurückzuspulen und die ursprüngliche Datei im Archiv zu überschreiben (was auf einem Band unmöglich wäre, wissen Sie). Zumindest glaube ich, dass das die Begründung für diese Erlaubnis war und das beabsichtigte Verhalten bei der Extraktion.

  2. JdeBP

    Es fehlt eine prominente tar-Implementierung. paxmirabilis ist tar, cpio und pax alles in einem, als Multiple-Call-Binary. Das ist tatsächlich das, was man in Debian als pax bekommt.

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

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

    Nein, es ist nicht libarchives bsdtar. Es gibt mehr als ein tar in der BSD-Welt.

  3. bartvk

    Dieser Typ, was für ein Held. Er hat sogar eine kleine Grafik eingefügt, um zu zeigen, wie dieser „schwierigste Tarball“ aussieht.

    Unten gibt es einen Link zu viel mehr Edge Cases.

    Das erinnert mich an diese Schönheit: „Parsing JSON is a Minefield“

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

  4. molticrystal

    >NET, Julia und uv's tar-codec - Diese Implementierungen lehnen den Tarball ab. Ich glaube, das ist das Beste, was man tun kann, auch wenn es technisch nicht POSIX-konform ist.

    Obwohl dies die sicherste Wahl ist, ist es die am wenigsten hilfreiche; ich würde immer lieber etwas aus einem Archiv herausholen als nichts. Schäden/Unregelmäßigkeiten an einem Archiv sollten die Dateninspektion nicht verhindern, sondern nur eine Warnung und eine Möglichkeit zum Rückgriff mit Einschränkungen für das, was extrahiert werden kann, bieten.

  5. zahlman

    > Dieser Tarball ist einer von 134 kniffligen Tarballs, die ich in meiner Testsuite haampie/tar-minefield sammle und kategorisiere

    Wäre „tarpit“ nicht ein viel natürlicherer Name?

Mehr von diesem Tag

2026-11-10