TAR in ZIP umwandeln

Wer ein deutsches Webhosting- oder Serverpaket nutzt, kennt die Situation: Die Exportfunktion für eine Datensicherung liefert eine .tar-Datei, obwohl auf dem eigenen Rechner nur der Windows-Explorer zur Verfügung steht, der mit dieser Endung nichts anzufangen weiß. Backup-Werkzeuge und Hosting-Oberflächen schreiben TAR gern als Zwischenformat, weil das eigentliche Programm dahinter ohnehin unter Linux läuft und dort seit jeher tar erwartet.

Das erklärt auch, warum das Archiv unkomprimiert ist: Das Programm, das es geschrieben hat, wollte es direkt an etwas anderes weiterreichen, und eine Komprimierung für eine Strecke von wenigen Zentimetern in derselben Infrastruktur wäre verschwendete Arbeit gewesen. Erst beim Wechsel auf einen Windows- oder Mac-Rechner wird daraus ein Problem.

Die meisten Archivumwandlungen auf dieser Website tauschen einen Kompressor gegen einen anderen, und die Größe bewegt sich dabei ein Stück in die eine oder andere Richtung. Diese hier startet bei null. TARs Kompression steht in unserem Register als „keine" — das Format schreibt Kopfdaten und Dateiinhalte hintereinander und rührt dabei kein einziges Byte an.

Ein ZIP desselben Inhalts ist also komprimiert, wo die TAR-Datei es nicht war, und beim Material, das eine Server-Sicherung meist enthält — Konfigurationsdateien, Datenbankauszüge, Protokolle, Quellcode — fällt der Unterschied deutlich aus. Es ist der seltene Fall, in dem Kompatibilitätsgewinn und Größengewinn in dieselbe Richtung zeigen, und der einzige Preis dafür ist der Verlust der Unix-Metadaten, der weiter unten steht.

TAR ist ein Strom fester 512-Byte-Blöcke. Jedes Mitglied kostet einen Kopfblock mit Name, Größe, Rechten und Zeitstempel, dazu seinen Inhalt, aufgefüllt bis zum nächsten Vielfachen von 512, und das ganze Archiv endet mit zwei Blöcken aus Nullen. Es gibt kein Inhaltsverzeichnis und keine zentrale Struktur.

Bei wenigen großen Dateien fällt das kaum auf. Bei einem Archiv mit tausenden kleinen Dateien — genau das, was eine Datenbanksicherung oder ein Quellcode-Export oft enthält — kann die Auffüllung allein einen spürbaren Teil der Dateigröße ausmachen. Ein ZIP hat pro Eintrag ebenfalls etwas Verwaltungsaufwand, aber nur wenige Byte statt einer Aufrundung auf ein halbes Kilobyte, und die Einträge sind zusätzlich komprimiert.

ZIP schreibt am Ende ein zentrales Verzeichnis, das jeden Eintrag mit seiner Position auflistet. Ein Programm kann den Inhalt eines großen Archivs damit lesen, ohne etwas zu entpacken, und eine einzelne Datei herausziehen, ohne die übrigen anzurühren — genau das, was ein ZIP im Windows-Explorer wie einen Ordner wirken lässt.

Eine TAR-Datei hat kein solches Register, deshalb bedeutet Auflisten, sie von vorn zu lesen, und eine Datei aus der Mitte zu holen bedeutet, an allem davor vorbeizulesen. Das ist eine Folge des Alters und Zwecks des Formats — TAR wurde 1979 für Magnetbänder entwickelt, bei denen Rückwärtssuchen keine Option war —, und es ist der Grund, warum jedes Archivwerkzeug mit einem ZIP zufriedener ist.

Eine TAR-Datei speichert Rechte, Benutzer und Gruppe für jedes Mitglied, und genau deshalb setzen Bereitstellungs- und Paketierungsabläufe auf dieses Format. ZIP hat dafür keinen von Desktop-Werkzeugen ausgewerteten Platz, sodass diese Angaben bei der Umwandlung nicht mitkommen.

Die Regel, die für alle Archivpaare hier gilt: Die Dateien kommen Byte für Byte heraus, gefährdet ist nur, was der Behälter über sie wusste — bei manchen Formaten ein Passwort, bei manchen die Rechte und Zeitstempel. Bei einer Server-Sicherung ist das relevant, weil ein Skript mit gesetztem Ausführungsrecht darin liegen kann, und nach dem Entpacken sollten diese Rechte gezielt neu gesetzt werden, falls etwas davon abhängt.

Der Größengewinn ist keine Selbstverständlichkeit. Enthält die TAR-Datei Fotos, Videos oder PDF-Dateien, findet DEFLATE fast nichts mehr, und das ZIP landet nur knapp unter der Größe der TAR-Datei minus ihrer Auffüllung.

Das lohnt sich vorher zu bedenken, bevor die Umwandlung als Lösung für ein Übertragungsproblem eingeplant wird. Ein 25-MB-Tarball voller JPEGs wird kein 6-MB-ZIP, und kein Kompressor der Welt macht daraus eines — diese Bytes wurden schon beim Kodieren der Fotos verbraucht. Was trotzdem bleibt, ist eine einzelne Datei, die jeder Rechner öffnet, was sehr oft der eigentliche Beweggrund für die Umwandlung ist.

Dieses Paar läuft auf unserem Server statt im Browser. Die TAR-Datei geht über eine verschlüsselte Verbindung hinüber, wird mit 7-Zip in ein Arbeitsverzeichnis entpackt, von dort als ZIP neu gepackt und zurückgeschickt; der Upload und jedes Zwischenergebnis werden gelöscht, sobald der Auftrag endet.

Der Arbeitsspeicher dafür ist ein begrenztes, speicherbasiertes Dateisystem, das zusammen mit dem Container verworfen wird, der den Auftrag ausgeführt hat. Die Grenzen sind 25 MB je Upload in der kostenlosen Nutzung und eine feste Obergrenze von sechzig Sekunden je Verarbeitungsschritt — beim Entpacken und beim Packen des ZIP läuft jeweils ein eigener Prozess mit eigenem Zeitfenster, sodass der ganze Auftrag in Summe auch länger dauern kann —, mit einer klaren Ablehnung jedes Archivs, das mehr als 2 GB entpackten Inhalt ankündigt. Da eine TAR-Datei unkomprimiert ist, liegt diese Ankündigung selten weit von der tatsächlichen Dateigröße entfernt.

Geht die Datei zurück in eine Linux-Umgebung, löst ZIP ein Problem, das dort gar nicht besteht. Die naheliegende Umwandlung ist dann, die TAR-Struktur zu behalten und nur zu komprimieren — eine Umwandlung nach GZ erzeugt die .tar.gz-Datei, die jedes Unix-Werkzeug mit einem Befehl auspackt, und behält dabei die Rechte und die Eigentümerangaben, die die TAR-Datei getragen hat.

ZIP ist die richtige Wahl, wenn eine Person auf Windows oder macOS die Datei öffnen muss oder ein Formular es verlangt. Ein komprimiertes Tar-Archiv ist richtig, wenn die Datei zurück in die Werkzeugkette geht. Der Unterschied ist keine Geschmacksfrage, sondern eine Frage danach, wer am anderen Ende sitzt.

Das ZIP gewinnt dabei eine Prüfung, die die Tarball-Datei nie hatte. TARs chksum-Feld deckt nur den Kopfblock ab, sodass ein beschädigtes Mitglied stillschweigend mit falschen Bytes entpackt wird; ZIP speichert pro Eintrag eine CRC-32-Prüfsumme und benennt den fehlerhaften Eintrag namentlich. Jedes Mitglied wird kopiert, ohne neu kodiert zu werden — ein verlustfreier Behälter hat von vornherein nichts, was neu kodiert werden müsste.

Anzahl der Einträge und Pfade sollten in beiden Archiven exakt übereinstimmen, und jedes Archivwerkzeug listet beide auf, ohne etwas zu entpacken — ein Vergleich ist damit eine Sache von dreißig Sekunden. Ein Blick lohnt sich zusätzlich auf die oberste Ebene: Eine aus einem übergeordneten Verzeichnis geschriebene TAR-Datei trägt in jedem Pfad einen führenden Ordner, eine von innen geschriebene nicht, und das ZIP gibt getreu wieder, was es vorgefunden hat.

Eine TAR-Datei aus einer Server-Sicherung oder einem Container-Export enthält oft Datenbankauszüge, Konfigurationsdateien und interne Verzeichnisse, die nicht dafür gedacht sind, in dieser Form von einer Person geöffnet zu werden. Die Umwandlung nach ZIP funktioniert einwandfrei und liefert genau diese Struktur, komprimiert, in einer Datei, die jeder Rechner öffnet.

Was sie nicht liefert, ist eine funktionierende Wiederherstellung. Eine Datenbank oder ein Dienst aus einer solchen Sicherung wiederherzustellen, braucht in aller Regel die ursprüngliche TAR-Struktur und das dazugehörige Werkzeug, nicht ein ZIP-Archiv. Ein umgewandeltes Archiv eignet sich also zum Durchsehen und Weiterreichen, und ob das Werkzeug, das die Sicherung geschrieben hat, die umgewandelte Fassung ebenfalls akzeptiert, ist eine eigene Frage, die sich vor dem Löschen des Originals klären lässt.