• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Fehlerausgabe bei unzip

Ich weiß nicht ob ich hier mit meiner Frage richtig bin, wenn nicht, dann bitte ins richtige Forum verschieben.
Folgendes:
Ich habe mir ein zip-File mit 1,6GB heruntergeladen. Wenn ich nun auf der Konsole unzip datei.name eingebe, dann wird das File entpackt und wenn es dann endlich fertig ist kommt die Fehlermeldung:
Code:
unzip hst15_kapitel01.zip
Archive:  hst15_kapitel01.zip
  inflating: hst15_kapitel01.avi
hst15_kapitel01.avi:  write error (disk full?).  Continue? (y/n/^C) y
 bad CRC 75514e08  (should be b19cf78e)

Was hat das zu sagen? Platte ist jedenfalls nicht voll, denn das entpackte File ist dort auch vorhanden.
 
OP
Pilz
Ist ein Reiser System. Das unterstütz soweit ich weiss mehr als 2GB. Wo kann ich die Änderung von ulimit vornehmen?
 
OP
Pilz
Code:
ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) 32
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) unlimited
cpu time             (seconds, -t) unlimited
max user processes            (-u) 3966
virtual memory        (kbytes, -v) unlimited

Täusch ich mich oder kann es daran nicht liegen?
Welcher Wert legt die maximale File-Size genau fest?

edit--------------
Uff, das Man von ulimit ist ja übel groß.
/edit-------------
 
ulimit scheints nicht zu sein, file size ist ja unlimited
eine möglichkeit wäre natürlich, dass unzip selbst nicht mit grossen files zurecht kommt, ich hab zb schon gzip's gesehen die's nicht können
 
Grothesk schrieb:
bad CRC 75514e08 (should be b19cf78e)

Da ist wohl das File kaputt. Musst du wohl noch mal laden...
Ich würde diese Idee nochmals verfolgen. Hast du binary oder ascii das File heruntergeladen? Alles andere als "binary" wäre hier falsch!
 
OP
Pilz
Was ich bis gestern Abend herausgefunden hatte war, daß zip und gzip und noch´n paar andere tatsächlich nicht über 2GB entpacken können. Die CRC Prüfsumme stimmt also wohl aus dem Grund heraus nicht, daß die Datei nicht vollständig entpackt wurde. Allerdings habe ich auch kein Lösungsweg gefunden, um zip davon zu überzeugen, daß mehr als 2GB entpacken soll. Soweit, detailierte Ausführung zu meinen weiteren Versuchen gibt es nachher. Ich muß jetzt erst nochmal weg.

edit-------------
Ich hab die Dateien allesamt aus dem Browser heraus via http heruntergeladen. Alle Dateien (10), die entpackt kleiner als 2GB sind, haben keine Probleme gemacht und sind auch vom Mplayer lesbar.
/edit------------
 
OP
Pilz
---------Fortsetzung-------
Mir scheint es, daß das zip-Format zu Win-lastig ist und deshalb unter Linux nicht weiter beachtet bzw. entwickelt worden ist. Unter WIN mit WinZip ist es kein Problem diese großen Dateien zu entpacken. Ich habe auch versucht, die Dateien zu splitten und anschließend zu entpacken oder auch wieder zusammenzufügen.

Code:
split -b 95m hst15_kapitel01.zip hst15_kapitel01.zip.split.
anschließend
Code:
cat hst15_kapitel01.zip.split.* | tar xz
Ich bekomme aber lediglich die Fehlerausgabe, dass das wohl keine tar-Datei sei. Ebenso weigert Ark sich diese Dateien zu entpacken.

Tja, so weit so gut (oder auch nicht)...........
Ich weiß mir nicht mehr zu helfen, da es scheinbar kein Prog unter Linux gibt, welches zip-Dateien dieser Größe händeln kann.
Wer einen Vorschlag hat, immer her damit. Bin für alles offen!

Grüße
Stefan
 
Pilz schrieb:
Was ich bis gestern Abend herausgefunden hatte war, daß zip und gzip und noch´n paar andere tatsächlich nicht über 2GB entpacken können.
Dann wurden die Programme vielleicht ohne -D_FILE_OFFSET_BITS=64 und ohne -D_LARGEFILE_SOURCE kompiliert. Auf 32-bit-Systemen können Dateien nämlich "eigentlich" gar nicht größer als 2 GB sein. Das geht nur, wenn die Programme, die mit so großen Dateien umgehen müssen, mit den genannten Flags kompiliert wurden.
Pilz schrieb:
Mir scheint es, daß das zip-Format zu Win-lastig ist und deshalb unter Linux nicht weiter beachtet bzw. entwickelt worden ist.
Quatsch. ZIP ist überhaupt nicht "Windows-lastig". Das ist eine sehr verbreitete "urban legend". Es unterstützt zwar DOS-Attribute, aber genauso unterstützt es auch UNIX-Berechtigungen.
Pilz schrieb:
Ich habe auch versucht, die Dateien zu splitten und anschließend zu entpacken oder auch wieder zusammenzufügen.
Code:
split -b 95m hst15_kapitel01.zip hst15_kapitel01.zip.split.
anschließend
Code:
cat hst15_kapitel01.zip.split.* | tar xz
Ich bekomme aber lediglich die Fehlerausgabe, dass das wohl keine tar-Datei sei.
Das kann gar nicht gehen, weil es Unsinn ist. Wieso willst Du denn eine gesplittete ZIP-Datei plötzlich mit "tar" entpacken? "tar" kann das einfach nicht, das hat auch nichts mit der Größe zu tun. Für ZIP-Archive ist "unzip" da.
Pilz schrieb:
Ich weiß mir nicht mehr zu helfen, da es scheinbar kein Prog unter Linux gibt, welches zip-Dateien dieser Größe händeln kann.
Es gibt zwei Möglichkeiten:

- Die Kompilations-Flags für "Large File Support" wurden bei SuSEs "unzip"-Paket vergessen, in diesem Fall könntest Du das Paket mit den Flags neu bauen und einen entsprechenden Bug-Report an SuSE schicken.
- Es handelt sich um non-standard-ZIPs, also um eine proprietäre Erweiterung durch WinZIP oder mit welchem Programm auch immer diese Archive erstellt wurden.

Installier mal das Paket "p7zip" von suser-guru, das ist ganz sicher mit den richtigen Flags kompiliert und außerdem weiß ich, dass die Windows-Version von 7-Zip auch non-standard-ZIPs unterstützt. "p7zip" ist die Linux-Portierung davon, also müsste es damit auch gehen.

Hier:

http://rpm.pbone.net/index.php3/stat/4/idpl/2448064/com/p7zip-4.30-1.guru.suse93.i686.rpm.html
http://rpm.pbone.net/index.php3/stat/4/idpl/2448060/com/p7zip-4.30-1.guru.suse100.i686.rpm.html

Bitte das richtige Paket passend zur SuSE-Version installieren, andernfalls wird es nicht gehen.

Und dann mit "7za" entpacken:
Code:
7za x <Dateiname>
PS: Wie ich gerade nochmal nachgelesen habe, ist Zip64 tatsächlich eine proprietäre Erweiterung, das normale ZIP unterstützt gar nichts über 2 GB und deswegen ist das auch kein Bug im "unzip"-Paket. Probier "p7zip" oder WinZIP mit WINE.

PS 2: https://bugzilla.novell.com/show_bug.cgi?id=138201
 
OP
Pilz
Hej traffic

Quatsch. ZIP ist überhaupt nicht "Windows-lastig". Das ist eine sehr verbreitete "urban legend". Es unterstützt zwar DOS-Attribute, aber genauso unterstützt es auch UNIX-Berechtigungen.
Nachdem, was ich auf meiner Suche so herausgefunden hatte, kam es mir so vor, daß das zip-Format unter Win mehr beachtet wird als unter Linux. Letztendlich meinte ich aber genau das was du geschrieben hattest.
- Es handelt sich um non-standard-ZIPs, also um eine proprietäre Erweiterung durch WinZIP oder mit welchem Programm auch immer diese Archive erstellt wurden.


Das kann gar nicht gehen, weil es Unsinn ist. Wieso willst Du denn eine gesplittete ZIP-Datei plötzlich mit "tar" entpacken? "tar" kann das einfach nicht, das hat auch nichts mit der Größe zu tun. Für ZIP-Archive ist "unzip" da.
In der Man tar steht:
Code:
-z, --gzip, --ungzip
filter the archive through gzip
Für mich sah es so aus, als ob tar mit zip-Dateien umgehen kann. Wenn ich da etwas falsch verstanden habe, dann erklär mir bitte wieso bzw. was. Und zip / unzip funktioniert nicht hinter Pipe.

Unter WinZip klappt es ohne Probleme die großen Dateien zu entpacken (hatte ich schon probiert). Aber das wäre ja langweilig und für mich auch unbefriedigend stehts auf Win-Programme zurück zugreifen. Und außerdem, wo bliebe denn da die Herausforderung?

Deine Tipps werde ich gleich mal ausprobieren und dann Ergebnisse posten.

Grüße
Stefan
 
1> write error (disk full?).
2> Was hat das zu sagen? Platte ist jedenfalls nicht voll, denn das entpackte File ist dort auch vorhanden.
1> Das schon mal beherzigt?
2> Jaja, aber ist das entpackte File auch VOLLSTÄNDIG, d.h. gibt "unzip -l bla.zip" dieselbe Dateigröße aus, wie die der entpackten Datei?
 
Pilz schrieb:
Code:
-z, --gzip, --ungzip
filter the archive through gzip
Für mich sah es so aus, als ob tar mit zip-Dateien umgehen kann.
Nein, gzip hat nichts mit ZIP zu tun. gzip selbst kann nichts mit ZIP-Archiven anfangen, also kann tar es ebenfalls nicht, auch nicht mit Hilfe von gzip.
Pilz schrieb:
Wenn ich da etwas falsch verstanden habe, dann erklär mir bitte wieso bzw. was. Und zip / unzip funktioniert nicht hinter Pipe.
Falsch verstanden hast Du wahrscheinlich, dass gzip etwas mit ZIP-Archiven anfangen kann, das kann es nämlich nicht.

Pipes gehen nicht vernünftig mit unzip, weil ZIP-Archive mehr als eine Datei enthalten können, was die Benutzung mit Pipes ziemlich witzlos macht. Man kann aber mit Hilfe von funzip zumindest den ersten Eintrag von ZIP-Archiven in Pipes benutzen:
Code:
cat "Archiv".zip | funzip > "erste Datei"
@jengelh: Nein, es völlig unnötig, weitere Zeit mit unzip zu verbringen. Ein ohne LFS-Flags kompiliertes Binary kann einfach nicht mit Dateien > 2 GB arbeiten, weder lesend noch schreibend. Deswegen habe ich doch den Bug an SuSE gemeldet.
 
OP
Pilz
@ traffic
So, dein Tip mit p7zip habe ich probiert. Und was soll ich sagen? Es hat funktioniert.

@all
Besten Dank für eure Hilfe

Problem gelöst und Thread für mich beendet.

Grüße
Stefan
 
Oben