[gelöst]entpacken mit tar schlägt fehl

[MaxMuster]

Nur nochmal um sicherzugehen, ob es am tar oder am packen liegt.
Könntest du erstmal versuchen, das File zu entpacken und dann erst zu ent-taren:
[coded]
gzip -d <Datei>.tar.gz
tar xvf <Datei>.tar
# oder auch mit
zcat <Datei>.tar.gz | ./busybox tar xvf -
[/code]

Das erste geht natürlich auch zusammen mit "gzip -d -c <die Datei mit .gz> | tar xvf -"

Jörg

 

[xxolli]

gzip -d <Datei>.tar.gz

entpackt mir ohne Meldungen eine <Datei>.tar
--> sollte demnach i.O sein

tar xvf <Datei>.tar

ergibt wieder ein

tar: corrupted octal value in tar header

Ein

gzip -d -c <die Datei mit .gz> | tar xvf -

ebenfalls.
genauso wie ein

zcat <Datei>.tar.gz | busybox tar xvf -

 

[olistudent]

Hast du mal im busybox-menuconfig nachgeschaut. Man kann das tar dort mit unterschiedlichen Optionen bauen...

MfG Oliver

 

[MaxMuster]

Dann ist es also ziemlich sicher das tar-Binary, was nicht mit dem .tar-File funktioniert. Du müsstest also ein "neueres" Tar bauen. Wenn ich gleich dazu komme, hänge ich mal ein aktuelles "echtes" tar (nicht das aus der Busybox) dran...


Jörg

EDIT ... oder Olivers Rat nachgehen, und ggf das Busybox-Tar "aufmotzen" ;-)
EDIT 2 Kompiliertes GNU-Tar 1.20 angehängt

 

[xxolli]

mit dem "neuen" tar geht´s.
krieg zwar noch folgende Fehlermeldung

A lone zero block at 345

aber entpackt ist es trotzdem

tausen Dank an Jörg und allen anderen hier

 

[archimedesmp]

Hi, tut mir leid, dass ich jetzt erst Antworte, aber das Studium lässt mir wenig Zeit.
Ich hab eben mal ein wenig Quellcode und Freetz-Config-Files gelesen.

1. busybox hat ein eingebautes tar, aber Freetz verwendet wohl ein das echte gnu tar (zumindestens wird das runtergeladen, aber ob es auch gebaut wird weiß ich nicht...)
2. tar hat früher wohl Leerzeichen vor dem Header des eigentlichen Archivs zugelassen, aber in neueren Versionen wurde dieses unnütze Feature abgeschafft. Die Abwärtskombatibilität hierzu kann man wohl in der BB mit einem Flag ein/ausschalten. In gnu tar selbst finde ich dazu nichts, weshalb ich vermute, dass die BB wohl doch ein eingebautes tar verwendet...

Quellcode in der BB (bei dd-wrt, aber BB ist BB ;-) )
http://svn.dd-wrt.com:8000/dd-wrt/b...chival/libunarchive/get_header_tar.c?rev=9719

Wäre evtl. einen Bugreport wert (vor allem interessiert mich warum das gnu tar runtergeladen (und wohl auch eingebaut?) aber das BB tar verwendet wird?)?

 

[Silent-Tears]

Das gnu-tar wird verwendet, um das Image zu packen. Um diversen Kompalibilitätsproblemen aus dem Weg zu gehen, die im Laufe der Zeit entstanden.

 

[archimedesmp]

Ich kann das Image mit meinem tar auch so entpacken, aber wenn das nicht immer klappt, ok.

Vielleicht sollte man trotzdem in der BB die Kompatibilität mit alten tar-Versionen beibehalten, da es von der Größe her ja quasi keinen Unterschied macht.