Verzechnisse ohne TAR gepackt - wie entpacken

[windreiter]

Hallo,

ich habe hier eine große gz-Datei, in der Ordnerstrukturen ohne tar gepackt sind.

Wie kann ich es wieder entpacken? In Fileroller ist angeblich nur eine Datei enhalten, tar -xzf sagt verständlicherweise dass es kein tar-Archiv ist.

Ich befürchte, dass die Dateien einzeln gepackt wurden und dann alle aneinandergereit (bitweise) in eine Datei geschrieben wurden. Wahrscheinlich gibts keine Chance mehr an die Dateien zu kommen?

[cirrussc]

Hi,

gunzip?
Wenn du nicht sicher bist was das ist: file <datei>.

[windreiter]

gunzip hatte ich auch schon probiert, schreibt aber auch nur alles in eine Datei keine Ahnung, was er da entpackt

[cirrussc]

Da wäre gut zu wissen, wie die Datei erstellt wurde und was wirklich drin steckt!
Vielleicht sind keine Dateien enthalten und es ist Beispielsweise nur eine log Datei oder ähnliches ->zcat.

edit: wenn er alles in eine Datei schreibt, dann ist es auch nur diese. Was zeigt denn:

Code: Alles auswählen

file <datei.gz>
gunzip -l <datei.gz>

Vielleicht wurde sie auch so erstellt: cat file1 file2 | gzip > foo.gz

[windreiter]

meine Recherchen haben meine Befürchtung wahr werden lassen, alle einzelnen gz-Files sind aneinandergereiht:
gzip -r -c -v -1 /quell/ordner/* > /ziel/datei.gz

[windreiter]

Mittels ghex habe ich herausgefunden, dass eine gz-Datei mit der Byte-Kobination "1F 8B 08 08" beginnt. (Dann folgen ein paat "zufällige" Bytes", dann kommt der echte Dateiname der komprimierten Datei im Klartext. Am Ende eine jeden gz-Files steht "00".

Welche Möglichkeiten habe ich, um jetzt die einzelnen gz-Dateien aus dem Bitstrom zu extrahieren?
Wie sähen geeignete sed-Optionen aus (so was wie: "schreibe alles zwischen zwei "1F 8B 08 08" in eine neue Datei und füge dort "1F 8B 08 08" am Anfang hinzu)?

Danke!

[Danielx]

Ich habe mal eben zum Spaß ein kleines C-Programm geschrieben, welches dir die aneinandergehängte datei.gz in einzelne .gz-Dateien zerlegt:
http://nopaste.debianforum.de/10628

Ist zwar auf die Schnelle und etwas kompliziert programmiert (wäre bestimmt auch einfacher mit einem Skript umzusetzen gewesen), aber es erfüllt seinen Zweck.
Es werden kaum Checks durchgeführt, also bitte in einem eigenen Ordner ausführen.

z.B so benutzen:

Code: Alles auswählen

mkdir /Verzeichnis/fuer/gz-Dateien/
cd /Verzeichnis/fuer/gz-Dateien/
/Pfad/zum/Programm/splitter /Pfad/zur/Datei/datei.gz

Jetzt hast du die große Datei in die einzelnen .gz-Dateien (Namen sind durchnummeriert: Splitdatei_Nr.gz) aufgeteilt.
Diese einzelnen .gz-Dateien kannst du jetzt entpacken, z.B. so:

Code: Alles auswählen

cd /Verzeichnis/fuer/gz-Dateien/
gunzip -N Splitdatei_*.gz

Da in der aneinander gehängten datei.gz leider die Dateinamen ohne den Pfad gespeichert sind, musst du aufpassen, dass sich dabei gleichnamige Dateien aus den einzelnen .gz-Dateien nicht überschreiben.
Die einzelnen .gz-Dateien werden automatisch gelöscht.

Ich habe einen Test mit mehreren hundert Dateien durchgeführt und das Ergebnis binär verglichen.
Die entpackten Dateien waren identisch zu den ursprünglichen Dateien.

Die datei.gz darf maximal 2GB groß sein.

Du hättest übrigens erwähnen können, dass du die Frage auch noch woanders gestellt hast:
http://ubuntuforums.org/showthread.php?p=5676283

Gruß,
Daniel

[yeti]

Du hättest übrigens erwähnen können, dass du die Frage auch noch woanders gestellt hast:
http://ubuntuforums.org/showthread.php?p=5676283

Was hätte das für einen Unterschied gemacht?

[Danielx]

Was hätte das für einen Unterschied gemacht?

Ich halte es nicht gerade für optimal wenn mehrere Menschen unabhängig von einander an dem selben Problem arbeiten und somit nicht die Erkenntnisse der jeweils Anderen mit in die eigenen Überlegungen einfließen lassen können.
Diese Diskussion gab es hier im Forum auch schon öfters.

Gruß,
Daniel

[yeti]

Diese Diskussion gab es hier im Forum auch schon öfters.

Tolle Aussage!
Die GEZ wird hier auch regelmäßig diskutiert und das beweist weder eine Qualität der Diskussion, noch die der dortigen Ergebnisse...

[tex]

Diese Diskussion gab es hier im Forum auch schon öfters.

Tolle Aussage!
Die GEZ wird hier auch regelmäßig diskutiert und das beweist weder eine Qualität der Diskussion, noch die der dortigen Ergebnisse...

Crossposting ist schon seit Uhrzeiten verpöhnt, finde dich damit ab.

[yeti]

Crossposting ist schon seit Uhrzeiten verpöhnt, finde dich damit ab.

Als ob ich von Dir Befehle entgegen nehmen würde... lächerlich!

EOT für mich!

[windreiter]

Ich habe mal eben zum Spaß ein kleines C-Programm geschrieben, welches dir die aneinandergehängte datei.gz in einzelne .gz-Dateien zerlegt

vielen Dank!

Die datei.gz darf maximal 2GB groß sein.

was passiert, wenn sie größer ist bzw. wie kann diese Beschränkung umgangen werden?

u hättest übrigens erwähnen können, dass du die Frage auch noch woanders gestellt hast

Entschuldigung, dies war nicht absichtlich. Eine Diskussion darüber wollte ich nicht auslösen!

[Danielx]

was passiert, wenn sie größer ist

Es wird eine Fehlermeldung ausgegeben (32-Bit): "<Datei> kann nicht geoeffnet werden"

wie kann diese Beschränkung umgangen werden?

Hier mal eine Version mit LARGEFILE64-Unterstützung:
http://nopaste.debianforum.de/10701
edit: Bitte in der Zeile 101 *argv ersetzen durch name

Wenn du allerdings Pech hast, dann kommt "1F 8B 08 08" nicht nur im Header vor, sondern auch in den komprimierten Daten.
Wenn die Identifizierung einer Datei fehlerhaft war, dann merkst du das aber beim gunzip...
Übrigens ist nur "1F 8B" der der eigentliche "Header", der Rest kann u.U. abweichen, siehe Spec.

Die Spec gibt es hier:
http://www.ietf.org/rfc/rfc1952.txt

Gruß,
Daniel

[windreiter]

das hat wunderbar geklappt - Danke!

Zur Info für jemanden der's auch braucht: es ist ein paar Mal vorgekommen, dass die Bytefolge auch in den Nutzdaten vorkam. Man kann das schnell erkennen, wenn man sich die Dateien mit "file" anguckt: Der angebliche Dateiname besteht dann nur aus kryptischen Zeichen. Mit "cat /Datei_ersterTeil /Datei_zweiterTeil > /neue Datei" kann das aber wieder einfach zusammengefügt werden.

Nochmals meinen herzlichen Dank!