XZ in TAR umwandeln

Wer mit Linux-Distributionen zu tun hat, kennt xz nicht als Exotenformat. Debian, viele RPM-basierte Systeme und nicht zuletzt Nürnberg — SUSE veröffentlicht seine Pakete und Quellarchive traditionell als .tar.xz, weil der Kompressionsgewinn gegenüber gzip bei Quelltext und Konfigurationsdateien erheblich ist. Wer an einem deutschen Rechenzentrum oder einer Hochschule mit einem HPC-Cluster arbeitet, lädt solche Archive routinemäßig herunter, oft mehrere Gigabyte an einem Nachmittag.

Der Grund, aus dem hier trotzdem jemand die Kompression wieder entfernen will, ist fast immer dasselbe: ein nachgelagertes Werkzeug, das ausdrücklich einen Tarball verlangt und mit xz nichts anfangen kann — ein Importskript für ein Cluster-Batchsystem, ein Deployment-Tool aus den Neunzigern, das seither zuverlässig läuft und niemand anfassen will, oder ein Container-Build, der eine unkomprimierte Ebene erwartet.

XZ komprimiert einen einzigen Datenstrom mit LZMA2 und kennt dabei weder Dateinamen noch Verzeichnisse — es sieht nur Bytes. Wer mehrere Dateien in einer .xz haben will, packt sie vorher in ein TAR, das aus dem Jahr 1979 stammt und als POSIX-Standard festgeschrieben ist: ein Kopfblock mit Name, Größe, Rechten und Zeitstempel pro Eintrag, ohne jede Kompression.

Beide zusammen ergeben genau das, was der Dateiname verspricht — erst bündeln, dann komprimieren —, und diese Umwandlung entfernt ausschließlich die äußere Schicht. Was herauskommt, ist der Tarball, der vor dem xz-Schritt existiert hätte, mit denselben Namen, Pfaden und Rechte-Feldern.

Anders als fast jede andere Archivumwandlung auf dieser Seite macht diese die Datei nicht kleiner, sondern deutlich größer — bei Quelltext, Log-Dateien und Konfigurationstexten oft um ein Vielfaches, weil xz mit einem Wörterbuch von bis zu 64 Megabyte arbeitet und dabei Wiederholungen findet, die ein Tarball ohne Kompression gar nicht erst zusammenfasst.

Für ein Rechenzentrum mit knappem Home-Verzeichnis oder ein Notebook mit halbvoller Platte ist das ein Faktor, den man vor der Umwandlung kennen sollte und nicht erst danach entdeckt. Wer den unkomprimierten Tarball nur kurz für ein Werkzeug braucht, sollte ihn danach wieder löschen, statt ihn neben der ursprünglichen .tar.xz liegen zu lassen.

Das ist der wichtigste Satz auf dieser Seite für alle, die ein veröffentlichtes Release umwandeln. Die Umwandlung löst die xz-Schicht nicht einfach ab, sondern entpackt das Archiv vollständig und schreibt aus dem Inhalt einen neuen Tarball. Die Dateien darin sind Byte für Byte identisch, weil das Entpacken verlustfrei ist. Der Tarball drumherum ist trotzdem ein neues Objekt.

Eine SHA-256-Prüfsumme aus den Release-Notizen, eine Signatur, ein Hash in einer Paketvorlage — nichts davon lässt sich gegen das hier heruntergeladene Ergebnis verifizieren. Wo Verifikation Teil der Arbeit ist, gehört das Entpacken lokal erledigt, mit xz -d archive.tar.xz, was ausschließlich die äußere Schicht anfasst und den Tarball unangetastet lässt. Diese Seite ist für den Fall gedacht, in dem ein Tarball existieren muss und seine exakten Bytes nicht Teil einer Zusage sind.

Ein TAR-Kopf hat Felder für Eigentümer, Gruppe, Zugriffsrechte und Änderungszeitpunkt, und für viele Archive sind diese Angaben wichtig — ein Installationsskript muss ausführbar ankommen, ein Cluster-Job erwartet bestimmte Zeitstempel für seine Abhängigkeitsprüfung. TAR ist genau das Format, das all das transportieren kann.

Was tatsächlich ankommt, hängt daran, was das ursprüngliche Archiv wirklich enthielt, denn die Umwandlung entpackt es und schreibt einen neuen Tarball aus dem, was dabei entsteht. Wer den Tarball anschließend in ein Deployment- oder Batchsystem einspeist, sollte die Rechte mit tar tvf vor dem eigentlichen Einsatz kurz prüfen, statt sich blind darauf zu verlassen.

Nicht jede .xz-Datei ist ein komprimiertes Archiv. Ein einzelner Datenbank-Dump, ein Messwertprotokoll oder ein Disk-Image wird ebenfalls oft einzeln mit xz komprimiert, ohne dass irgendwo ein Tarball beteiligt ist — xz komprimiert schließlich nur einen Strom, egal was darin steht.

Der Umwandler versucht nach dem Entpacken, einen inneren Tarball zu erkennen, und wenn das fehlschlägt, wird stattdessen die eine gefundene Datei genommen und als einziges Mitglied in ein TAR geschrieben. Das ist kein Fehler, sondern die einzig ehrliche Antwort auf eine .xz, die nie ein Verzeichnis enthalten hat.

Um einen xz-Strom zu entpacken, braucht der Rechner einen Puffer in der Größe des Wörterbuchs, mit dem die Datei geschrieben wurde — laut Registrierung bis zu 64 Megabyte. Auf einem gewöhnlichen Rechner oder Server fällt das nicht auf, weshalb dieses Detail selten zur Sprache kommt.

Es wird relevant, wenn der eigentliche Grund für die Umwandlung ein Gerät mit wenig Arbeitsspeicher ist, das xz gar nicht selbst entpacken kann — ein altes Embedded-System, ein minimaler Container ohne eigene Kompressionswerkzeuge. Dann tauscht man Speicherbedarf gegen eine größere Datei, und das ist ein legitimer Grund, nicht bloß ein Nebeneffekt.

Die Umwandlung läuft nicht im Browser, sondern auf unserem Server, weil dafür echte Programme wie 7-Zip und xz gebraucht werden. Die Datei geht verschlüsselt dorthin, wird in einem Arbeitsverzeichnis entpackt, das keinen Zugang zum Internet hat, und dieses Verzeichnis wird gelöscht, sobald der Auftrag endet — auch wenn er scheitert.

Die freie Nutzung erlaubt 25 Megabyte je hochgeladener Datei, und ein einzelner Verarbeitungsschritt wird nach sechzig Sekunden abgebrochen. Vor dem Entpacken wird geprüft, wie groß das Archiv laut eigener Angabe werden soll, und ein Wert über zwei Gigabyte wird abgelehnt, bevor überhaupt etwas geschrieben wird — bei diesem Umwandlungspaar durchaus relevant, weil das Ergebnis grundsätzlich viel größer ist als das, was hochgeladen wurde.

tar tvf archive.tar listet jeden Eintrag mit Rechten, Eigentümer, Größe und Zeitstempel auf, ohne etwas auszupacken. Wichtig ist zuerst die oberste Ebene: Ein Archiv, das aus einem Verzeichnis heraus gepackt wurde, und eines, das aus dessen übergeordnetem Ordner stammt, unterscheiden sich durch einen führenden Pfadbestandteil, und ein Importwerkzeug, das das eine erwartet und das andere bekommt, meldet einen Fehler, der wie ein fehlendes Verzeichnis aussieht.

Zweitens lohnt ein Blick auf die Rechtespalte, besonders wenn etwas aus dem Archiv später ausgeführt werden soll. Das ausführbare Bit ist genau das, was bei diesem Umweg am ehesten verlorengeht — und wenn es fehlt, lässt sich das nachträglich mit chmod korrigieren, statt es erst auf dem Zielsystem zu bemerken.

Geht das Archiv an ein Linux-System, einen Build-Agenten oder ein Container-Image, ist die Umwandlung meist ein Schritt zurück: Dort ist xz ohnehin installiert, die entstehende ZIP- oder TAR-Datei ist deutlich größer zu übertragen, und ein direktes xz -d archive.tar.xz auf der Zielmaschine erledigt dasselbe ohne den zusätzlichen Umweg über einen Webdienst.

Diese Seite verdient ihren Platz dort, wo ein Werkzeug schlicht kein xz spricht und niemand die Berechtigung oder die Zeit hat, es nachzuinstallieren — etwa ein altes, aber unverzichtbares Skript in einem Rechenzentrum, das seit Jahren zuverlässig Tarballs entgegennimmt und nichts anderes.