TAR in GZ umwandeln

Reine TAR-Dateien sind seltener als gezippte und tauchen an erkennbaren Stellen auf. `docker save` schreibt eine. Ein Backup-Skript, das gebündelt, aber nicht komprimiert werden sollte — bei einem selbstgeschriebenen Cronjob eines Azubis oder eines Praktikanten liegt der Fehler oft in einem einzigen fehlenden Buchstaben: `tar cf` und `tar czf` unterscheiden sich nur um ein `z`, und nur eine der beiden Varianten macht die Datei kleiner.

Das Ergebnis ist ein Archiv, das ungefähr der Summe aller enthaltenen Dateien plus einem überraschenden Anteil an Overhead entspricht. Auf der lokalen Festplatte ist das egal und überall sonst teuer: bei einem Upload über eine langsame Leitung, in einem Objektspeicher-Bucket, der pro Gigabyte-Monat abrechnet — deutsche Hosting-Anbieter wie Hetzner oder IONOS berechnen Traffic anders, aber die Zeit für den Upload zählt trotzdem —, im Anhanglimit einer E-Mail, in einem CI-Cache, der bei jedem Build erneut geladen wird. Diese Umwandlung ist eines der wenigen Repacks auf dieser Seite, bei denen die Antwort fast immer Ja lautet, weil es keinen Kompatibilitätspreis gibt — `.tar.gz` wird universeller verstanden als ein bloßes `.tar`.

Der Aufbau von TAR stammt aus dem Jahr 1979 und ist bestechend simpel: ein 512-Byte-Header, der eine Datei beschreibt, dann die Datei selbst, aufgefüllt auf die nächste 512-Byte-Grenze, dann der nächste Header, und am Ende zwei Nullblöcke als Abschluss. Nichts wird komprimiert und nichts indiziert. Das Format wurde für Bandlaufwerke entworfen, bei denen feste Blockgrößen genau der Punkt waren.

Bei kleinen Dateien zeigt sich der Preis dafür. Eine Ein-Byte-Datei belegt in einer TAR-Datei 1.024 Byte — einen vollen Header-Block und einen vollen Datenblock. Zehntausend Konfigurationsdateien, Quelldateien oder JSON-Dokumente mit im Schnitt ein paar hundert Byte tragen mehrere Megabyte Header und Füllmaterial ohne jede Information. Gzip ist genau darin sehr gut: lange Nullfolgen komprimieren zu fast nichts, ein großer Teil der Ersparnis bei einem Archiv aus vielen kleinen Dateien kommt also aus dem Entfernen von Overhead, nicht aus der Komprimierung des Inhalts.

Gzip nutzt DEFLATE mit einem 32-KB-Verlaufsfenster, und diese Zahl entscheidet über alles bei dieser Umwandlung. Innerhalb jedes 32-KB-Abschnitts findet es wiederholte Zeichenfolgen und ersetzt sie durch Verweise, danach wird der Rest Huffman-kodiert. Bei Text, Code, Logs, XML, JSON und Konfigurationsdateien ist das eine große und verlässliche Ersparnis.

Was es übersieht, ist Wiederholung über größere Entfernungen. Steht derselbe Lizenzkopf in zweihundert Dateien verteilt über ein 40-MB-Tarball, komprimiert gzip ihn zweihundert Mal separat, weil es nie zwei davon gleichzeitig sieht. Genau diese Lücke schließen XZ und 7Z, weshalb sie gzip bei Archiven aus vielen ähnlichen Dateien deutlich schlagen. Gzips Antwort darauf ist, dass es schnell ist, sich streamen lässt und praktisch überall installiert ist — für eine Datei, die verschickt statt aufbewahrt wird, meist der bessere Tausch.

Das lohnt sich, deutlich zu sagen, weil es überrascht, wer eine Hülle um die eigene Datei erwartet. Die Umwandlung entpackt die hochgeladene TAR-Datei und schreibt aus dem entpackten Inhalt eine neue TAR-Datei, die dann mit gzip komprimiert wird. Die enthaltenen Dateien sind Byte für Byte identisch; der Tarball drumherum ist ein frischer.

Zwei Folgen ergeben sich daraus. Erstens stimmt eine gegen das Original veröffentlichte Prüfsumme mit nichts hier überein, weil die ursprüngliche TAR-Datei nicht mehr vorliegt — muss ein Hash geprüft werden, die Datei stattdessen mit `gzip` auf dem eigenen Rechner komprimieren, das lässt den Tarball unangetastet. Zweitens kann sich verschieben, was der alte Container über seine Mitglieder gespeichert hatte: Rechte und Zeitstempel sind die Felder, die dabei gefährdet sind. Für ein Quellcode-Bündel oder ein Dokumentenarchiv spielt das keine Rolle, für ein Deployment-Artefakt schon.

Ein gzip-Stream trägt ein Header-Feld für den ursprünglichen Dateinamen, weshalb `gunzip backup.gz` auf einem Unix-Rechner eine Datei namens `backup.tar` erzeugen kann, obwohl im Befehl selbst nichts das gesagt hat. Es ist eine kleine Höflichkeit, die das Format bietet, und der Grund, warum eine gzip-Datei etwas weniger anonym ist als eine xz- oder bzip2-Datei, die beide gar keinen Namen speichern.

Darauf sollte man sich für nichts Wichtiges verlassen. Manche Werkzeuge schreiben einen allgemeinen Namen in dieses Feld, andere ignorieren es beim Entpacken, und eine Datei, die durch ein System läuft, das Archive neu schreibt, verliert ihn ganz. Die Endung, die man der heruntergeladenen Datei gibt, ist das, was tatsächlich gelesen wird — also `.tar.gz` verwenden statt `.gz` und der Gegenseite das Auspacken eines Rätsels ersparen.

Ein gzip-Stream wird von vorn nach hinten mit einem festen 32-KB-Fenster ohne Index dekodiert, was nach einer Einschränkung klingt und der Ursprung seines größten Vorteils ist. Es bedeutet, dass das Archiv verarbeitet werden kann, während es ankommt: `curl https://… | tar xzf -` entpackt einen Download, der nie auf der Festplatte landet, ein Backup lässt sich direkt in gzip hinein und aus ihm heraus auf einen entfernten Host leiten, und ein Log-Versand kann on-the-fly komprimieren, ohne zu wissen, wie viel Daten noch kommen.

Genau das ist der Grund, warum gzip in zwanzig Jahren voller stärkerer Konkurrenten nicht verdrängt wurde. Formate mit einem großen Wörterbuch brauchen Speicher proportional dazu; Formate mit einem zentralen Verzeichnis brauchen das Ende der Datei, bevor sie den Anfang auflisten können. Wird der Tarball gepiped, über HTTP ausgeliefert oder von etwas Kleinem entpackt, ist gzip nicht der Kompromiss — es ist die richtige Wahl.

Die drei sind nicht gestaffelt, sie sitzen an unterschiedlichen Punkten derselben Kurve. Gzip ist beim Komprimieren und Entpacken am schnellsten und spart am wenigsten. XZ spart bei Text mit Abstand am meisten, zum Preis einer langen Komprimierzeit und des Speichers, den das Entpacken braucht. BZ2 liegt beim Verhältnis dazwischen, entpackt langsam, und die Registry markiert es als veraltet.

Entscheiden lässt sich das danach, was mit der Datei als Nächstes passiert. Etwas, das wiederholt von Maschinen abgerufen und entpackt wird, über eine Pipe — gzip. Etwas, das jahrelang in einem Archiv liegt und fast nie gelesen wird — XZ. Etwas, das einen Artefaktnamen treffen muss, den ein Build-System schon erwartet — was auch immer dieser Name vorgibt, ohne weiteres Nachdenken. Einen Tarball umzuwandeln ist billig genug, um zwei Varianten auszuprobieren und die Größen zu vergleichen.

Nicht im Browser. Die meisten Werkzeuge hier laufen auf dem eigenen Gerät, und das steht auch so da; das Umpacken von Archiven ist eine der Ausnahmen, weil dafür 7-Zip und gzip als echte Programme gebraucht werden. Die Datei reist über eine verschlüsselte Verbindung zu einem Container, der diese Programme ausführt und keinen eigenen ausgehenden Internetzugang hat.

Jeder Auftrag bekommt ein eigenes Arbeitsverzeichnis, das gelöscht wird, sobald der Auftrag endet, gleich mit welchem Ergebnis; alles, was nach sechzig Sekunden noch läuft, wird beendet statt weiterlaufen gelassen. Die freie Stufe nimmt 25 MB je hochgeladener Datei an, und bei diesem Paar spürt man diese Grenze am stärksten — eine TAR-Datei ist unkomprimiert, 25 MB TAR sind also 25 MB tatsächlicher Inhalt, während 25 MB 7Z das Zehnfache sein könnten.

`tar xzf archiv.tar.gz` erledigt beide Schichten in einem Durchgang unter macOS, Linux und den BSDs, und modernes Windows bringt in PowerShell und der Eingabeaufforderung ein `tar`, das dasselbe tut. Grafische Archivierer unter Windows entpacken meist nur die gzip-Schicht und hinterlassen eine `.tar`-Datei zum erneuten Öffnen — genau das Verhalten, das Leute nach einem einzigen Container-Format suchen lässt.

Vor dem Löschen des Originals die Auflistung vergleichen: `tar tzf` auf dem Ergebnis gegen `tar tf` auf der Quelle, gleiche Anzahl, gleiche Pfade. Die oberste Ebene ist dabei das Entscheidende, denn ein Archiv, das von innerhalb eines Verzeichnisses gepackt wurde, und eines, das von dessen übergeordnetem Verzeichnis gepackt wurde, unterscheiden sich durch einen führenden Ordner bei jedem Eintrag — und ein Skript, das das eine erwartet und das andere bekommt, scheitert Monate später aus Gründen, an die sich niemand mehr erinnert. Stimmen beide Auflistungen überein, hat die unkomprimierte TAR-Datei keine Aufgabe mehr.

Geschäftsunterlagen, die nach deutschem Handels- und Steuerrecht sechs oder zehn Jahre aufzubewahren sind, landen bei vielen Unternehmen als Ordner-Exporte oder Datenbank-Dumps in einem Backup-System, oft als TAR gebündelt, bevor sie auf einen Langzeitspeicher wandern. Über zehn Jahre und mehrere Systemgenerationen hinweg ist der Speicherplatz, den ein unkomprimiertes Archiv zusätzlich braucht, kein einmaliger Posten, sondern einer, der jeden Monat erneut anfällt.

Das ist der eigentliche wirtschaftliche Grund, ein Backup-Skript zu korrigieren, das TAR ohne `z` aufruft, statt es Monat für Monat unkomprimiert weiterlaufen zu lassen. Die Komprimierung nachträglich mit dieser Umwandlung anzuwenden behebt die aktuelle Datei; das Skript selbst zu korrigieren behebt das Problem für jede zukünftige.