Das TAR Dateiformat

Ich bin (leider) nicht alt genug, als dass ich den Einsatz von Bandkassetten zur Datenspeicherung live mitbekommen hätte. Disketten waren für mich von 1995 bis 2003 das “älteste” Medium.

Doch dank Unix und seinen Linuxsprösslingen haben “Band-Archive” bzw. Tape-Archives, kurz TAR, als primitives Dateiformat bis heute überlebt.

Grund genug dieses Format selbst zu implementieren.


Als Windows-Kind ist das ZIP Format für mich die absolute Nummer eins wenn es um die komprimierte Archivierung von Verzeichnissen geht. Denn seit Windows XP kann der Explorer diesen Dateityp ohne Zusatzprogramme öffnen und bearbeiten.

Tatsächlich habe ich aber TAR schon vor ZIP genutzt, denn vor meinem Einstieg ins Internet gegen 2001 habe ich privat überhaupt keine “Archive” benutzt und alles unkomprimiert gespeichert. (OK, die Disketten-Orgie mit MSBACKUP sei hier mal schnell verdrängt.)

Und es war wohl ein paar Jahre vor dem Jahrtausendwechsel, als ich meine erste Linux-Test-Installation von den damals üblichen PC-Heft-CDs aufsetzte.
Es kann sich heute keiner mehr vorstellen was für ein unerträglicher Krampf das mit Linux war, wo auf CD Nr.1 ein Basis-Linux per Start-Diskette auf den Rechner gewurschtelt wurde und auf CD Nr. 2. fand man dann jede Menge “Archive”, die man manuell entpacken und kompilieren musste.

Und so führte ich tatsächlich ein tar -xf irgendwas.tar.gz wie im Heft beschrieben aus, lange bevor ich meine Dateien per Windows Explorer als ZIP verstaute.

TAR selbst gemacht

Kurz auf gnu.org/software/tar geblickt:

 1struct posix_header
 2{
 3  char name[100];     /* path: "path/to/file.txt" */
 4  char mode[8];       /* octal file-mode bits */
 5  char uid[8];        /* owner user id */
 6  char gid[8];        /* owner group id */
 7  char size[12];      /* octal file size */
 8  char mtime[12];     /* octal unix timestamp */
 9  char chksum[8];     
10  char typeflag;      /* '0'==file, '5'==directory, 'L'==long-link */
11  char linkname[100];        /* "path/to/linked.file" */
12  char magic[6];      /* "ustar\0" */
13  char version[2];           /* "00" */
14  char uname[32];            /* owner user name */
15  char gname[32];            /* owner group name */
16  char devmajor[8];
17  char devminor[8];
18  char prefix[155];
19};

Wie alt und primitiv TAR ist, sieht man schon an seinem Header, der immer 512 Bytes groß sein muss und mit genau 100 Bytes für den Dateinamen beginnt. Hmm … 100 Zeichen für einen ganzen Pfad? Da konnte selbst DOS mit 255 mehr. Zahlen für Dateiattribute, Größe und Zeitstempel liegen als ASCII-formatierte Oktalzahlen vor.

Dass dieses Format aus der Unix-Welt stammt sieht man dann an der UID und GID, sowie weiteren 100 Zeichen für einen Link-Namen. In den Anfängen von Unix waren auch dort die Dateisysteme nicht in der Lage, mehr als ein paar Zeichen pro Datei zu speichern und so empfand man ganze 100 Bytes als üppig dimensioniert.

Doch wegen dieser Einfachheit lässt sich das Format mit wenigen C-Zeilen selbst implementieren. Man füllt einen 512 Header aus, der die nachfolgende Datei beschreibt und danach werden einfach die Rohdaten hinten angestellt. Ist die Dateigröße kein genaues Vielfaches von 512, dann müssen so viele Null-Bytes nachgeschoben werden, bis ein 512er Block voll ist. Und im Anschluss daran folgt der nächste Datei-Header der auch wieder von den Rohdaten gefolgt wird. Am Ende schreibt man dann noch genau ein Kilobyte Nullen daran (also zwei leere 512-Byte Blöcke) und die TAR Datei ist fertig.

Auf zwei Dinge muss man aufpassen:

  • TAR-interne Dateipfade müssen mit Slashes zur Pfadkomponententrennung nutzen
  • Und wir MÜSSEN eine Prüfsumme über den Header berechnen.

Die Prüfsumme ist mir bei der Implementierung sehr auf die Nerven gegangen. Man muss dafür den Header voll ausfüllen und die Bytes der Prüfsumme “leer” lassen. Und mit “leer” sind “Blank” also Leerzeichen (Space) notwendig. Ich hatte den Bereich aber ausgenullt und wunderte mich dann, weshalb 7-Zip und das tar Tool die Datei als korrupt zurückwiesen.

Lange Dateinamen

Am meisten interessiert mich ja, wie Workarounds aussehen, um “historische” Limits zu umgehen.
TAR löst das 100 Zeichen pro Datei-Limit durch die Möglichkeit von “Vendor-Extentions”. Und eine bekannte GNU Erweiterung dafür sind LongLink Header.

Man erstellt also einen üblichen 512-Byte Dateiheader, doch anstatt des Dateinamens steht in den ersten 13 Bytes der Token ././@LongLink und das Header-Type Byte steht auf L. Und das Größen-Feld wird auf die länge des vollständigen Dateinamens gesetzt. Nach dem LongLink-Block kommt dann der Dateiname genau so wie bei den Rohdaten in 512-Byte Häppchen und der letzte Block muss dann auch wieder mit Nullen aufgefüllt werden.
Nun folgt der “richtige” Header unserer Datei, wo in den ersten 100 Zeichen der Anfang des Dateinamens abgebildet ist. Alle anderen Felder sind genau so ein gesetzt, wie für die Rohdaten notwendig und danach werden ebenso die Rohdaten (wieder mit 512-Byte Vervollständigung) angefügt.

Man hat also quasi einen Präfix-Block + Meta-Daten und danach den eigentlichen Datei-Header und die echten Daten, die zusammengefasst dann die endgültige Datei beschreiben.

Naja…. offen gesagt schon etwas primitiv … aber so ist das eben bei den alten Dateiformaten.

Fazit

Bisher hatte ich TAR nur über Bibliotheken und CLI Tools genutzt. Doch wenn man diesen Kuchen selbst backt, merkt man erst, wie krümelig er innen drinnen ist.

Erweiterungen und “andere Interpretationen” gibt es leider einige und somit ist man wohl besser beraten, eine fertig Lib zu nutzen, die alle Rafinessen dafür bereits drauf hat.

Doch wenn es nur darum geht, die eigenen Dateien schnell und unkompliziert zu archivieren, so lege ich jedem ans Herz diesen Implementierungs-Tag mal zu investieren.
Denn viele Libs und Tools sind heute mit Zusatzfunktionen und Abhängigkeiten gespickt, die einem unkompliziertem Deployment im Wege stehen.

Da ziehe ich dann mein 400 Zeilen Eigenfabrikat vor, das nur stdio.h und string.h braucht um TAR Archive zu erzeugen. Dann fährt noch die ZLIB darüber und schon haben wir ein TAR.GZ, so wie es im Buche steht.

Wieder was gelernt und daher einen schönen Tag gehabt! So kann’s gerne weitergehen.


Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!