TAR in BZ2 umwandeln

Fast niemand entscheidet sich hier frei — jemand oder etwas hat es vorgegeben. Ein Paketrezept nennt „.tar.bz2" als Quelle und prüft dagegen eine Prüfsumme. Ein Projekt liefert seit vielen Jahren unter genau dieser Endung aus, und Mirrors, Download-Seiten und fremde Build-Skripte zeigen alle darauf. openSUSE, gepflegt von SUSE mit Sitz in Nürnberg, nutzte bzip2 über Jahre als Standard für RPM-Pakete, und ein Teil der damaligen Infrastruktur erwartet die Endung bis heute unverändert.

Keine dieser Stellen wird sich wegen einer einzelnen Datei ändern, und keine liegt damit falsch — der Dateiname ist Teil einer Vereinbarung, gegen die andere bereits gebaut haben. Das macht diese Umwandlung zu einer Frage der Konformität, nicht der Optimierung. Wer frei wählt und niemand nachgelagert etwas dagegen hat, sollte diese Seite verlassen und stattdessen zu gzip oder XZ greifen.

Bzip2, aus dem Jahr 1996, arbeitet strukturell anders als seine beiden Nachbarn. Es zerlegt die Eingabe in Blöcke von bis zu 900 Kilobyte und wendet auf jeden eine Burrows-Wheeler-Transformation an, die Bytes so umordnet, dass gleichartige Kontexte nebeneinander landen. Ein Move-to-Front-Durchgang und Huffman-Kodierung verdichten anschließend die entstandenen Läufe. Es ist überhaupt kein Sliding-Window-Kompressor.

Die Registry führt den 900-Kilobyte-Block als Fenstergröße, und diese Zahl ist der faire Vergleichspunkt gegenüber gzips 32 Kilobyte: Innerhalb eines Blocks sieht bzip2 weit mehr Kontext, als gzip je sehen kann, weshalb es bei Text die Nase vorn hat. Es ist auch der faire Vergleich zu XZs 8-Megabyte-Wörterbuch, wo bzip2 verliert — ein 900-Kilobyte-Block kann nicht bemerken, dass eine Datei am Anfang des Archivs einer am Ende ähnelt. Bzip2 liegt genau in der Mitte, und genau das ist der Grund, warum es zunehmend verdrängt wurde.

Kompression ist langsam, weil das Sortieren aufwendig ist, und das ist ein Preis, den man einmal zahlt, auf einer Maschine, die nicht auf einen wartet. Das ist erträglich. Die Überraschung liegt beim Entpacken: Einen Blocksort rückgängig zu machen, ist echte Arbeit, ganz anders als das Auflösen eines Sliding-Window-Treffers, sodass bzip2 beim Entpacken deutlich langsamer ist als gzip und auch langsamer als xz.

Das macht das Format zur schlechten Wahl für alles, was wiederholt heruntergeladen und entpackt wird. Eine Abhängigkeit, die bei jedem CI-Lauf neu geholt wird, eine Container-Ebene, ein Artefakt, das von hundert Maschinen gezogen wird — jede einzelne zahlt den Entpackungspreis bei jedem Mal, und bei einem großen Archiv sind das Minuten statt Sekunden. Bzip2 ist erträglich für etwas, das einmal geschrieben und einmal gelesen wird. Es ist echt teuer für etwas, das einmal geschrieben und ständig gelesen wird.

Der Speicherbedarf beim Entpacken. Bzip2 arbeitet in Blöcken von höchstens 900 Kilobyte, deshalb ist der Puffer, den es zum Entpacken braucht, klein und fest, egal wie groß das Archiv ist. XZ braucht Speicher, der mit dem Wörterbuch skaliert, mit dem die Datei geschrieben wurde — die Registry führt hier 8 Megabyte als Standardwert —, und kann die Maschine ihn nicht bereitstellen, öffnet sich das Archiv gar nicht erst.

Das trifft heute auf weniger Orte zu als früher, aber diese Orte sind real: Router und eingebettete Geräte, speicherbegrenzte Container, Wiederherstellungsumgebungen, ein Initramfs, ein altes System, das niemand aktualisieren darf. Muss das Archiv an einer solchen Stelle entpackt werden, ist bzip2 eine begründete technische Entscheidung, keine Gewohnheit aus alter Zeit — und es lohnt sich, das in den Release-Notes festzuhalten, damit es die nächste Person nicht für einen Fehler hält.

BZ2 komprimiert genau einen Datenstrom. Es kennt kein Feld für einen Dateinamen, keine Vorstellung von einem Verzeichnis und keine Möglichkeit zu markieren, wo ein Element endet und das nächste beginnt — die Registry führt das Fehlen jeder Verzeichnisstruktur als bekannte Eigenschaft des Formats. Alles, was ein Blick in ein „.tar.bz2" zeigt, wird aus dem TAR-Archiv darin gelesen.

Die Umwandlung entpackt also das Gesendete, schreibt ein neues TAR-Archiv aus dem Inhalt und komprimiert dieses mit bzip2. Das Archiv wird aus dem obersten Verzeichnisinhalt aufgebaut, sodass die eigenen Dateien direkt zuoberst liegen statt in einem zusätzlichen Ordner. Der Download kommt mit der Endung „.bz2" an und sollte in „.tar.bz2" umbenannt werden — korrekt und zugleich die Form, mit der `tar xjf` beide Ebenen in einem einzigen Befehl erledigt.

Bzip2 komprimiert seine Blöcke unabhängig voneinander, was dem Format eine Eigenschaft gibt, die seine Nachbarn nicht haben: Ein beschädigter Block zerstört nicht zwangsläufig alles, was danach kommt. Es gibt Werkzeuge, die eine defekte bzip2-Datei durchgehen, intakte Blockgrenzen finden und retten, was noch lesbar ist.

Das ist eher ein Trost als eine Strategie. Das TAR-Archiv darin ist ein zusammenhängender Strom aus Headern und Daten, und geretteter Block hier und dort ergibt eine Tar-Datei mit Löchern, deren Nutzbarkeit ganz davon abhängt, wo der Schaden lag. Ist Widerstandsfähigkeit gegen Bitfehler eine echte Anforderung, liegt die Antwort in einem Format mit Prüfsummen je Element und eigener Parität, nicht in einem Kompressor mit einem hilfreichen Fehlerverhalten.

Die Umwandlung legt bzip2 nicht einfach um die hochgeladene Datei. Sie entpackt das TAR-Archiv und schreibt ein neues, das anschließend komprimiert wird. Die Dateien darin sind Byte für Byte identisch — dieser Schritt ist verlustfrei —, aber das Archiv drumherum ist neu, und die Reihenfolge der Elemente, gespeicherte Zeitstempel und Berechtigungsbits können vom Gesendeten abweichen.

Für jemanden aus dem Paketbau ist genau dieses Detail entscheidend dafür, ob dieses Werkzeug das richtige ist. Prüft das Rezept eine Prüfsumme des Artefakts, muss das Artefakt deterministisch auf einer selbst kontrollierten Maschine entstehen, mit `tar --sort=name --mtime=…` und `bzip2` für die eigentliche Arbeit. Dieser Konverter passt, wenn irgendein „.tar.bz2" existieren muss — für einen Spiegelserver, eine Kollegin, ein Upload-Formular, einen Test —, nicht wenn die exakten Bytes Teil der Vereinbarung sind.

Auf unserem Server, nicht im eigenen Browser. Viele Werkzeuge dieser Seite laufen auf dem eigenen Gerät und sagen das auch — Archivarbeit ist eine der Ausnahmen, weil sie echte Programme braucht. Die Datei geht über eine verschlüsselte Verbindung an einen Container mit 7-Zip und bzip2, und dieser Container hat keinen eigenen Weg ins Internet.

Jeder Auftrag bekommt ein eigenes, speicherbasiertes Arbeitsverzeichnis, das nach Abschluss verworfen wird, ob erfolgreich oder nicht, und jeder Auftrag, der nach sechzig Sekunden noch läuft, wird beendet. Diese Grenze wird hier eher erreicht als bei den meisten anderen Paaren, weil bzip2-Kompression langsam ist — ein großes Textarchiv ist genau die Eingabe, die sich Zeit lässt. Die kostenlose Stufe akzeptiert 25 Megabyte je hochgeladener Datei.

Die einzige ehrliche Verhältniszahl ist die, die man an den eigenen Daten misst, und das dauert zwei Minuten: dasselbe TAR-Archiv als GZ, als BZ2 und als XZ komprimieren und die drei Größen nebeneinanderlegen. Bei einem Quellcode-Baum oder einer Sammlung von Logdateien ist die Reihenfolge vorhersehbar — XZ am kleinsten, BZ2 dazwischen, GZ am größten —, aber die Abstände schwanken je nach Inhalt erheblich, und bei einem Archiv bereits komprimierter Dateien liegen alle drei innerhalb einer Rundungsdifferenz.

Dann noch das abwägen, was keine Dateiliste zeigt: Wie oft wird das entpackt, und von was? Gzip, wenn die Antwort „ständig, von Maschinen" lautet. XZ, wenn die Antwort „fast nie, von einem normalen Rechner" lautet. Bzip2, wenn etwas es vorgegeben hat oder die Gegenstelle sehr wenig Speicher hat. Bzip2 allein wegen des Kompressionsverhältnisses zu wählen, ist eine Entscheidung, die vor zwanzig Jahren sinnvoll war und still aufgehört hat, es zu sein.