AK's weblog

Heute stand ich vor dem interessanten Problem, eine Datei zu recovern, die Kollegen von einem alten Rechner von mir gebackuped hatten. Und zwar war dieses Backup in Form einer .tar.bz2-Datei abgelegt. Grundsätzlich keine blöde Idee, denkt man sich, weil man alle Dateien schön komprimiert zusammengepackt hat. Nicht so in meinem Fall: es macht absolut keinen Spaß, ein tar tjf <archiv> laufen zu lassen, wobei die gesamte Datei dekomprimiert wird, und ein Listing des gesamten Archivs erstellt wird, und dann in einem zweiten Durchgang die betroffene Datei zu extrahieren, wobei die gesamte Datei noch einmal dekomprimiert wird. Das kann ja wohl nicht Sinn der Sache sein. Wohlgemerkt: das .tar.bz2-File hat eine Größe von etwa 10 GB.

Wenn man schon komprimierte Archive will, dann sollte man das doch lieber folgendermaßen gestalten: man packt alle Dateien zusammen, quasi die Umkehrung eines .tar.bz2: zuerst die Dateien komprimieren, und dann zu einem Archiv zusammenfassen. Und zur weiteren Beschleunigung stellt man ganz vorne an die Datei einen Header mit den wichtigsten Infos zu den enthaltenen Dateien (möglicherweise inklusive Dateinamen). Und um das ganze "verlängerbar" zu machen, packt man in diesen Header auch noch einen Offset zum nächsten Header dieser Art hinein.

Eine Alternative zu dieser verketteten Liste an Headern wäre auch noch folgendes: wenn lt. Header das Ende der Datei erreicht sein müsste, aber noch nicht EOF gefunden wurde, dann findet sich dort der nächste Header (natürlich muss der Header die Länge der dazugepackten Daten wissen, was das Format als Ausgabeformat nicht streambar macht). Durch die nicht mögliche "Streambarkeit" verliert die Konstruktion ihren "unixigen" Charakter, der allerdings durch eines wieder wettgemacht wird: wenn man den Weg der in diesem Absatz beschriebenen Alternative wählt, so genügt ein cat <archiv1> <archiv2> > <archiv3>, um mehrere derartige Archive zu einem zusammenzufügen.

Als Kompressionsalgorithmus innerhalb des Archivs würden sich mehrere Optionen anbieten, wie etwa die weit verbreiteten gzip oder bzip2 oder aber eine Integration der zlib. Eine weitere Alternative wäre einer der Kompressionsalgorithmen von oberhumer.com.

Wer meine Ausführung für wirr hält, dem kann ich teilweise recht geben, und wie meistens wird dies wahrscheinlich auch nur ein Hirngespinst bleiben, wer sowas jedoch implementieren will, den kann ich dabei nur (moralisch) unterstützen. Eventuell künftig existierende Implementierungen werden auf jeden Fall hier announced werden.