ZIP in TAR umwandeln

Zum Aufbewahren wandelt das niemand um. Der Anlass ist immer etwas, das weiter unten in der Kette ausschließlich Tarbälle frisst: ein Build-Kontext für einen Container, ein Ausrollschritt, eine Importschnittstelle, ein Skript, das vor fünfzehn Jahren gegen tar geschrieben wurde und seitdem klaglos seinen Dienst tut. TAR stammt aus dem Jahr 1979 und ist als POSIX-Standard festgeschrieben; als die meiste Infrastruktur entstand, war ein Archiv schlicht ein Tarball.

Damit ist das hier eine Verträglichkeitsumwandlung, im selben Sinn, in dem ein PDF eine Verträglichkeitsumwandlung für ein Dokument ist. Du machst das Archiv nicht besser, du machst es annehmbar, und bezahlst dafür in Bytes. Der Erfolgsmaßstab ist deshalb, ob das Werkzeug am anderen Ende aufhört zu meckern — nicht, wie die Dateigröße aussieht. Meist ist der Tarball danach auch entbehrlich: Wenn der Build gelaufen ist, bleibt das ZIP die Fassung, die man aufhebt.

Das ist der Satz, den die meisten Seiten zu diesem Thema weglassen. Ein ZIP komprimiert jeden Eintrag, den es enthält. Ein TAR komprimiert gar nichts — es reiht Dateien aneinander und hört damit auf. Beim Umwandeln wird die Kompression also aufgelöst und nicht ersetzt, und heraus kommt ungefähr die unkomprimierte Summe dessen, was im ZIP steckte.

Wie stark es zulegt, hängt am Inhalt. Bei Quelltext, Protokolldateien, CSV-Ausgaben und XML ist der Faktor am größten, weil sich genau solche Daten hervorragend komprimieren lassen und das Rückgängigmachen entsprechend teuer ist. Ein ZIP voller JPEGs, MP4s oder PDFs wächst dagegen kaum, denn diese Dateien waren schon komprimiert, bevor sie ins Archiv kamen. Es lohnt sich, vorher zu wissen, in welchem der beiden Fälle du bist — vor allem, wenn der Tarball anschließend noch durch eine Leitung muss.

Ein Tarball ist ein Strom fester Blöcke zu je 512 Byte. Jeder Eintrag bekommt einen Kopfblock mit Name, Größe, Rechten und Zeitstempel, danach folgt sein Inhalt, aufgefüllt bis zum nächsten Vielfachen von 512, und am Ende stehen zwei Blöcke aus Nullen. Es gibt kein Inhaltsverzeichnis, keine Kompressionstabelle und kein zentrales Register wie im ZIP.

Bemerkbar macht sich das bei Archiven mit sehr vielen winzigen Dateien. Fünfhundert Dateien zu je einem Kilobyte kosten mindestens einen Kopf- und zwei Inhaltsblöcke pro Stück, und allein die Auffüllung ist dann messbar. Das ist der zweite Grund, aus dem ein Tarball eines Quellbaums neben dem ZIP, aus dem er stammt, seltsam groß wirkt — unabhängig davon, dass die Kompression verschwunden ist.

Ein guter Teil derjenigen, die nach dieser Umwandlung suchen, braucht in Wahrheit ein komprimiertes Archiv, weil in der Anleitung, der sie folgen, ein Dateiname mit zwei Endungen stand. Wenn das Ziel ein Download, ein Veröffentlichungsartefakt oder irgendetwas ist, das über ein Netz geht, ist der nackte Tarball die falsche Hälfte der Antwort.

Wandle das ZIP in dem Fall nach GZ statt nach TAR. Jedes Ziel hier, das von Haus aus nur eine einzige Datei aufnehmen kann — GZ, BZ2 und XZ —, wird gebaut, indem zuerst ein TAR entsteht und dieses dann komprimiert wird. Genau das bedeutet die Endung .tar.gz seit jeher. Kurz gefasst: TAR, wenn ein Werkzeug einen Tarball erwartet; GZ, wenn ein Mensch etwas herunterladen soll.

Ein TAR kann Dateirechte, Benutzer und Gruppe festhalten — genau deshalb mögen Unix-Werkzeuge das Format. Erfinden kann es diese Angaben nicht. Was im Tarball landet, stammt aus dem Auspacken deines ZIPs auf unserem Umwandler und nicht von der Maschine, auf der die Dateien ursprünglich lagen.

Behandle die Rechte im Ergebnis deshalb als unbestimmt und nicht als übernommen, und setze sie nach dem Auspacken ausdrücklich, wenn etwas davon abhängt. Das ausführbare Bit an einem Skript ist der übliche Verlust und der, der am spätesten auffällt — nämlich dann, wenn der Ausrollschritt mit Permission denied abbricht. Die Dateien selbst kommen Byte für Byte heraus; gefährdet ist das, was das Archiv über sie wusste, nicht das, was in ihnen steht.

Wer im deutschsprachigen Raum mit Archiven arbeitet, kennt Ordner mit Namen wie Prüfbericht Abschlussprüfung, und er kennt auch, wie sie aussehen, wenn etwas schiefgegangen ist. ZIP hat die Namen seiner Einträge historisch in einer DOS-Zeichentabelle abgelegt und erst später ein Kennzeichen bekommen, mit dem ein Archiv erklären kann, dass seine Namen in UTF-8 stehen. Ältere Programme setzen dieses Kennzeichen nicht.

TAR wiederum legt Namen als Bytes ab und macht über deren Bedeutung überhaupt keine Angabe. Beide Formate reichen das Problem also weiter, statt es zu lösen. Wirf nach dem Auspacken einen Blick in die Namensliste, bevor der Tarball in einen automatisierten Schritt geht — ein Dateiname, den ein Skript nachher nicht findet, ist ein ärgerlicherer Fehler als einer, der sofort auffällt. Wenn du Einfluss auf das Erzeugen des ZIPs hast, ist die dauerhafte Lösung, es mit UTF-8-Kennzeichen schreiben zu lassen.

Archive umzupacken ist eine der wenigen Aufgaben hier, für die eine richtige Maschine nötig ist. Die Datei geht deshalb verschlüsselt an unseren Umwandler, dort packt 7-Zip das ZIP aus und schreibt den Tarball, das Ergebnis kommt zurück, und das Arbeitsverzeichnis wird gelöscht, sobald der Auftrag endet — auch dann, wenn er scheitert. Es liegt im Arbeitsspeicher und nicht auf einer Platte.

Der Tarball wird übrigens von innerhalb des ausgepackten Verzeichnisses gebaut. Das ist der Unterschied zwischen einem Archiv, das deine Dateien enthält, und einem, das einen zusätzlichen Ordner enthält, in dem deine Dateien liegen — und der Grund, warum die Pfade im Ergebnis dort beginnen, wo du sie erwartest. Die Grenzen dieser Bauweise sind 25 MB je Datei, hundert Serverumwandlungen am Tag und ein harter Abbruch nach sechzig Sekunden. Für ein Umpacken dieser Größe ist eine Minute großzügig; sie steht da, weil ein absichtlich verbogenes Archiv einen Packer eher ins Kreisen bringt als zum Fehler.

Erstens: ein Archiv, das von sich behauptet, sich auf mehr als 2 GB auszupacken. Das wird abgelehnt, bevor auch nur ein Byte geschrieben wird — der Schutz gegen ein ZIP, das gebaut wurde, um ein Dateisystem vollzuschreiben. Zweitens: ein ZIP, in dem am Ende nichts drin ist. Es gibt dann eine verständliche Meldung statt eines leeren Tarballs, den niemand brauchen kann.

Drittens: ein verschlüsseltes ZIP. Der Entpacker bekommt bewusst ein leeres Kennwort mit auf den Weg, damit ein geschütztes Archiv sofort und lesbar scheitert, statt auf eine Eingabe zu warten, die nie kommt. Nimm den Schutz in dem Fall lokal ab und wandle das offene Archiv. Ein Kennwort gehört zu den Dingen, die ein Behälter über seinen Inhalt weiß — und die ein TAR ohnehin nicht ausdrücken könnte.

Dieser Fall verdient eine ausdrückliche Ansage, weil andere Werkzeuge ihn unterschiedlich handhaben. Wenn dein ZIP eine einzelne TAR-Datei enthält, kommt genau diese TAR-Datei im neuen Archiv wieder — als Datei, verpackt in den neuen Tarball. Sie wird nicht ausgepackt und ihr Inhalt nicht nach oben gezogen.

Das ist Absicht. Ein TAR, das jemand in ein ZIP gelegt hat, ist eine Datei, die dort hingehört, und keine Verpackungsschicht. Anders liegt der Fall bei den Formaten, die von Natur aus nur eine einzige Datei aufnehmen können: Bei einem GZ, BZ2 oder XZ ist ein enthaltenes TAR fast immer die zweite Schicht derselben Verpackung, und dort wird sie folgerichtig aufgelöst. Der Unterschied zwischen beidem ist der Unterschied zwischen einer Schachtel in einer Schachtel und einer Schachtel mit Deckel.

Das geht, und es ist der übliche Abschluss dieser Geschichte: Der Tarball hat seinen Zweck erfüllt, der Build ist gelaufen, und jetzt soll die Sammlung wieder handlich werden. Ein TAR zurück in ein ZIP zu packen, ist hier genauso eine Umwandlung wie der Hinweg, und dabei komprimiert das ZIP das, was der Tarball unkomprimiert vor sich hertrug.

Was diese Runde nicht leistet, ist eine Rückkehr zum Original. Der Inhalt kommt unversehrt zurück — die Dateien sind Byte für Byte dieselben —, aber Rechte und Zeitstempel sind inzwischen zweimal durch ein Auspacken gegangen, und ein ZIP könnte Unix-Rechte ohnehin nur eingeschränkt festhalten. Wenn du das ursprüngliche Archiv noch hast, ist es die bessere Kopie. Der Rückweg ist für den Fall gedacht, dass es das Original nicht mehr gibt.

Für die lange Aufbewahrung hat TAR eine Eigenschaft, die den komprimierten Formaten fehlt: Schaden bleibt örtlich. Eine kaputte Stelle in einem unkomprimierten Tarball kostet die Dateien an dieser Stelle, und alles danach lässt sich weiterhin lesen, weil die Struktur nichts weiter ist als Köpfe und Inhalte in Reihe, ohne gemeinsamen Zustand zwischen den Einträgen. Ein Werkzeug, das die Blöcke abläuft, steigt über den Schaden hinweg.

Ein komprimiertes Archiv verzeiht sehr viel weniger. Ein falsches Byte früh in einem durchgehenden Strom kann alles danach unbrauchbar machen, weil jede spätere Rückverweisung auf korrekt dekodierten früheren Inhalt aufbaut. Das ist das ehrliche Argument dafür, einen einfachen Tarball neben einer komprimierten Kopie zu halten statt an ihrer Stelle: das komprimierte Archiv fürs Bewegen, das unkomprimierte fürs Überleben.

ZIP erledigt Verpacken und Komprimieren in einem Aufwasch. Das ist bequem und nimmt dir stillschweigend eine Wahl ab: Das Archiv ist komprimiert, weil ZIP das eben macht, und zwar in der Stufe, die das schreibende Programm gerade für richtig hielt. Ein TAR trifft diese Entscheidung nicht. Es hat keine Stufe, kein Verfahren und kein Wörterbuch — es notiert, wie die Dateien heißen, legt ihre Bytes in Reihe und ist fertig.

Genau diese Trennung ist der Grund, warum sich Unix-Werkzeuge so frei kombinieren lassen. Derselbe Tarball kann durch gzip laufen, wenn es schnell gehen soll, durch xz, wenn es klein werden soll, oder durch gar nichts, wenn er nur ein Zwischenschritt ist — und wer ihn bewegt, entscheidet darüber, nicht wer ihn gepackt hat. Wenn du einen Tarball wolltest, weil eine spätere Stufe ihre Artefakte selbst komprimiert, hast du diese Entscheidung bewusst getroffen, und das größere Ergebnis ist das richtige.