7Z in GZ umwandeln

In vielen mittelständischen IT-Abteilungen ist 7-Zip die Hausvorgabe, und der Grund ist selten Vorliebe, sondern Lizenzpolitik: Es ist quelloffen und kostenlos, während WinRAR nach der Testphase kostenpflichtig wird und in einer größeren Organisation eine Beschaffung nach sich zieht, die niemand für ein Packprogramm anstoßen will. Die Kollegen im Fachbereich archivieren also als 7Z, ohne dass es je zum Problem wird — bis eine Datei in eine Linux-Umgebung soll.

Genau dort beginnt diese Seite. Eine GitLab-CI-Pipeline, ein Debian-Server, ein Docker-Build-Kontext erwarten einen Tarball, kein 7Z, und dort etwas zu ändern ist meist aufwendiger, als die eine Datei umzuwandeln.

Ein 7Z komprimiert seine Einträge als einen einzigen durchgehenden Strom mit einem LZMA2-Wörterbuch von 16 MB in der Standardeinstellung. Gzip arbeitet dagegen mit einem 32-KB-Fenster. Rund fünfhundertmal weniger Reichweite, dazu ein Kodierverfahren, das selbst innerhalb dieses Fensters weniger effizient ist als LZMA2.

Bei einem Archiv aus vielen ähnlichen Textdateien — Quellcode, Protokolle, Konfigurationsdateien — fällt der Unterschied am größten aus, weil genau solche Daten besonders gut komprimieren und der Verlust beim Wechsel entsprechend teuer ist. Bei Fotos, MP4s oder PDFs im Archiv liegen beide dicht beieinander, weil in beiden Fällen kaum noch etwas zu komprimieren übrig ist.

GZ komprimiert genau einen Byte-Strom und kennt weder Namen noch Pfade noch Rechte. Ein 7Z ist das Gegenteil: ein eigenes Verzeichnis von Einträgen mit eigenen Prüfsummen und eigener Verschlüsselung. Der Wechsel zwischen beiden braucht deshalb einen Zwischenschritt, und dieser Schritt ist TAR.

Die Inhalte werden als Tarball angeordnet, der all das trägt, was Gzip nicht speichern kann, und Gzip komprimiert diesen Tarball dann als ein einziges Objekt. Das ist nichts, was dieser Umwandler erfindet — es ist, was `.tar.gz` seit den frühen Unix-Systemen bedeutet, und genau deshalb erkennt die Pipeline am anderen Ende das Ergebnis, ohne dass ihr irgendetwas über die Herkunft erklärt werden müsste.

Gzip ist das einzige Archivformat in unserem Register, das als „streaming" markiert ist, und genau das ist der Grund, warum es überall installiert ist. Ein Gzip-Strom lässt sich von vorne dekomprimieren, während die Bytes noch ankommen, ohne dass erst das Ende der Datei gelesen werden muss.

Deshalb funktioniert `curl … | tar -xz`, und deshalb kann ein Build-Server ein Artefakt bereits entpacken, während es noch heruntergeladen wird. Ein 7Z kann das nicht: Seine Struktur muss zuerst gelesen werden, bevor sich überhaupt sagen lässt, wo ein Eintrag liegt, also muss die Datei erst vollständig vorliegen, bevor irgendetwas entpackt werden kann. Für eine Pipeline ist dieser Unterschied mehr wert als die eingesparten Megabyte.

Jede Linux-Distribution, jede macOS-Installation und jedes Container-Image, das auf einer davon aufbaut, hat Gzip an Bord. Für xz gilt das auf einem minimalen Image schon nicht mehr uneingeschränkt, für 7-Zip praktisch nie. Eine bewusst leere Basis führt allerdings auch kein Gzip mit sich — Dockers `scratch` und Googles Distroless-Images liefern keinen Gzip-Binär mit —, was sich vor dem Bauen prüfen lässt statt vorausgesetzt werden sollte.

Wenn die Anforderung lautet „muss auf dem anderen Ende laufen, ohne dass dort etwas installiert wird", ist das die Rechnung, um die es geht, und der Grund, warum dieses Format-Paar überhaupt existiert.

Der Download übernimmt den ursprünglichen Dateistamm und hängt die Zielendung an, sodass aus `sicherung.7z` ein `sicherung.gz` wird, obwohl der Inhalt ein gezippter Tarball ist. Die meisten Unix-Werkzeuge erkennen das an den Bytes selbst, manche Skripte und Webserver tun es nicht.

Umbenennen in `.tar.gz` oder in `.tgz`, das unser Register als dieselbe Form unter kürzerer Schreibweise führt, kostet nichts und verhindert eine ganze Klasse von Verwirrung — einschließlich des klassischen Falls, dass jemand die Datei entpackt, ein TAR findet und annimmt, die Umwandlung sei fehlgeschlagen.

Solide Kompression ist genau die Eigenschaft, die das 7Z klein gemacht hat, und dieselbe Eigenschaft macht es umständlich umzupacken. Weil die Einträge ein einziger durchgehender Strom sind, bedeutet das Erreichen irgendeines Eintrags, alles davor zu entpacken — die Umwandlung baut deshalb erst das ganze Archiv aus, bevor auch nur ein Byte Tar geschrieben wird. Entpacken, Eintüten ins TAR und Gzip-Komprimierung laufen dabei als mehrere Werkzeugaufrufe hintereinander, nicht als einer.

Deshalb zählen hier die Sechzig-Sekunden-Grenze je einzelnem Schritt und die 2-GB-Auspack-Sperre mehr als bei einem TAR-Quellformat — ein Auftrag mit mehreren Schritten kann in Summe länger als sechzig Sekunden dauern, solange keiner der Schritte für sich diese Grenze reißt. Ein dicht gepacktes 7Z ist ein kleiner Upload, der einen sehr großen Arbeitsaufwand darstellen kann, und die Schutzgrenzen lesen, was das Archiv über sich selbst behauptet, bevor irgendetwas geschrieben wird — nicht erst, wenn es zu spät ist.

Diese Umwandlung läuft nicht im Browser, sondern auf unserem Umwandlungsserver. Das 7Z geht über eine verschlüsselte Verbindung hoch, wird dort in einem eigenen, frisch angelegten Arbeitsverzeichnis ausgepackt, in ein TAR gelegt und gezippt; das Original, der Zwischenschritt und das Ergebnis werden gelöscht, sobald der Auftrag endet — auch bei einem Fehler.

Die kostenlose Stufe nimmt 25 MB je Datei an. Ein verschlüsseltes Archiv scheitert sofort mit einer Meldung statt endlos zu warten, weil dem Entpacker absichtlich ein leeres Kennwort mitgegeben wird, und ein Archiv, das sich als leer herausstellt, bekommt einen klaren Satz statt eines gültigen, aber nutzlosen Downloads.

Landet der Tarball ohnehin komplett auf der Platte, bevor irgendetwas ihn anfasst, ist der Streaming-Vorteil von Gzip nichts wert, und die schwächere Kompressionsrate kostet bei jedem Download bar. Eine Umwandlung des 7Z nach XZ bleibt bei derselben LZMA-Familie, liefert eine deutlich kleinere Datei und kostet in einem Ablauf, der ohnehin nie etwas verketten sollte, nichts.

Umgekehrt gilt: XZ braucht mehr Speicher beim Entpacken, weil der Decoder das ganze Wörterbuch vorhält, es ist nicht in jedem minimalen Container-Image vorhanden, und es lässt sich nicht von vorn aus dem Strom lesen. Gzip für Pipelines und für Ziele, die man nicht kontrolliert; XZ für Downloads und Releases, bei denen eine Datei viel öfter heruntergeladen als gebaut wird.

Die TAR-Ebene trägt zu jedem Eintrag einen Modus, einen Benutzer und eine Gruppe, weshalb Paketwerkzeuge überhaupt einen Tarball verlangen. Erfinden kann sie diese Werte nicht: Sie stammen aus dem Entpacken auf unserem Umwandlungsserver, nicht von der Maschine, auf der die Dateien ursprünglich angelegt wurden — sie sind also unbestimmt, nicht übernommen.

Für ein Build-Artefakt ist das meist harmlos. Für alles Ausführbare nicht: Ein Skript, das sein Ausführbarkeits-Bit verliert, scheitert zur Laufzeit mit einem Fehler, der auf das Skript zeigt und nicht auf das Archiv, das es transportiert hat. Hängt eine Pipeline von Rechten ab, sollte sie diese im Build-Schritt nach dem Auspacken explizit setzen, unabhängig davon, welches Werkzeug den Tarball gebaut hat.