CRC-Fehler beim Entpacken von ZIP / Owncloud

[Gem]

Hallo zusammen,

ich bekomme beim Versuch, ZIP-Dateien (wie jetzt festgestellt nur bei den ZIPs, die mir Owncloud erzeugt) mit dem TC (8.51a, unter Nutzung des internen ZIP-Entpackers) zu entpacken, folgende Fehlermeldung:

Code: Select all

CRC-Fehler beim Entpacken von
<DATEI>, Datei gelöscht!

Sowohl über den (Windows-)Explorer als auch mit WinRAR lassen sich die Archive fehlerfrei entpacken.
Auch die Option "Behalte defekte Dateien (CRC-Fehler)" ändert das Verhalten nicht.

Die beiden unten aufgeführten Topics liefern leider keine Lösung.

Jemand eine hilfreiche Idee?

http://ghisler.ch/board/viewtopic.php?t=35988
http://ghisler.ch/board/viewtopic.php?t=22388

[Horst.Epp]

Hilfreich wäre es vor allem, wenn du hier ein Muster angehängt hättest.
Oder wie soll Christian aus deiner Beschreibung das Problem finden ?

[Gem]

Zunächst hatte ich auf Hilfestellung durch die Community gehofft, vl. hat ja jemand das gleiche Problem und schon eine Lösung parat.

Hier aber natürlich auch eine von Owncloud generierte Datei:
test.zip

[ghisler(Author)]

Die Datei scheint gar keine CRC-Quersummen zu enthalten - wenn man mit F3 reinschaut und auf Hex-Modus umschaltet, sieht man das an den vielen FF FF FF FF-Blöcken.

Bei mir erscheint der Fehler auch wenn man defekte Dateien behalten will, aber die Datei wird einwandfrei entpackt.

[Gem]

Ja, der "Fehler" liegt am ZIP, das OC (Beta) erstellt - das ist ja auch nicht komprimiert.

Mich hat eben nur verwundert, dass die anderen Programme das Archiv ohne Warnung/Fehler entpacken und ich im TC unter Verwendung der Option "defekte Dateien behalten" bei jeder Datei bestätigen muss, dass ich sie behalten will.

Da das ein sehr spezieller Einzel(fehler?)fall ist, ist das Thema damit auch erledigt.

Danke für die Antwort.

[ghisler(Author)]

TC ist halt etwas pingeliger - wenn der CRC-Quersummenwert gibt es immer eine Warnung.

[Gem]

Guten Tag,

mittlerweile ist das "Problem" auch bei OC angekommen, vielleicht für Sie Herr Ghisler ganz interessant:

https://github.com/owncloud/core/issues/10001

[McNetic]

Hallo, ich bin der Entwickler von PHPZipStreamer, der Komponente, die ab Owncloud 7 für das Zippen verantwortlich ist.

Ich hatte mit TC8.50 mal mit meinen Zip-Files getestet, und damals keine Probleme festgestellt. Leider habe ich diese Version nicht mehr verfügbar.

Soweit ich es sehe, sind die CRCs in der Zip-Datei völlig in Ordnung. Die FFFF sind die Größen (komprimiert/unkomprimiert), die im Header (standardkonform) auf -1 gesetzt werden, da die Zip64-Extension genutzt wird und die Größen am Schluss im Zip64 extended information field stehen. Kannst Du das noch mal prüfen?

Achja: Dass die Dateien nicht komprimiert sind, ist auch standardkonform; die Gründe sind in einem Kommentar in dem bereits verlinkten issue bei Owncloud zu finden.

[tbeu]

TC8.50 kannst du hier herunterladen. Der CRC-Fehler von test.zip kommt da aber auch.

[ghisler(Author)]

2McNetic
Edit: Total Commander unterstützt eigentlich nur die 32-bit-Variante des extended information field. Weil aber der CRC-Wert am Anfang steht (entweder direkt, oder hinter "PK"0708), spielt das keine Rolle, weil TC nur das CRC-Feld auswertet.

Das Problem ist, dass das "extended information field" bei der Owncloud-generierten ZIP-Datei komplett fehlt (siehe Link weiter oben). Nach dem (unkomprimierten) Dateiinhalt kommt direkt das central directory ("PK"01 02).

[McNetic]

Hallo, ich würde gerne auf Deinen Post antworten, müsste dabei aber zwei Links angeben - das darf ich aber nicht. Kannst Du das freischalten? Danke.

[CoolWater]

Sollte ab dem 3. Post gehen. Also einfach einen weiteren Post erstellen.

[McNetic]

Ah, ok. In der Fehlermeldung stand nach dem ersten Post.

Also ich habe jetzt nochmal die Spezifikation gewälzt ( https://www.pkware.com/documents/casestudies/APPNOTE.TXT ). Was bei meinen Zip-Dateien fehlt, ist der "data descriptor". Dieser ist laut Spezifikation optional. Es gibt ein Flag, mit dem man seine Anwesenheit anzeigen kann - das ist bei mir nicht gesetzt.

Eine Recherche zeigte, dass die gleiche Frage bei der Entwicklung von JDK7 auftrat, und die Entwickler haben bei PKware nachgefragt:
https://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of
Recht weit unten auf der Seite sieht man, dass die Antwort ist, dass "data descriptor" nicht gleichzeitig mit dem "zip64 extended information field" verwenden soll. Korrigier mich bitte, wenn ich das falsch verstanden habe - mir geht es nicht darum, den schwarzen Peter umherzuschieben, sondern eine standardkonforme Implementierung zu haben, die (im Rahmen der Spezifikation) mit möglichst vielen Programmen kompatibel ist.

Der korrekte CRC-Wert für jede Datei steht übrigens (auch, in meinem Fall nur) im "central directory header".

[ghisler(Author)]

Das ist falsch - der "data descriptor" muss vorhanden sein, wenn Grössen und CRC NICHT im Header stehen.

Code: Select all

      This descriptor exists only if bit 3 of the general
      purpose bit flag is set (see below).  It is byte aligned
      and immediately follows the last byte of compressed data.
      This descriptor is used only when it was not possible to
      seek in the output .ZIP file, e.g., when the output .ZIP file
      was standard output or a non-seekable device.  For ZIP64(tm) format
      archives, the compressed and uncompressed sizes are 8 bytes each.

       Bit 3: If this bit is set, the fields crc-32, compressed 
                 size and uncompressed size are set to zero in the 
                 local header.  The correct values are put in the 
                 data descriptor immediately following the compressed
                 data.

So wie ich das verstehe, darf das CRC-Feld im Local Header nur dann einen ungültigen Wert enthalten, wenn man Bit 3 setzt UND den data descriptor sendet.

[white]

Was bei meinen Zip-Dateien fehlt, ist der "data descriptor". Dieser ist laut Spezifikation optional. Es gibt ein Flag, mit dem man seine Anwesenheit anzeigen kann - das ist bei mir nicht gesetzt.

Diese Flag ist aber doch gesetzt ins test.zip oben.

Eine Recherche zeigte, dass die gleiche Frage bei der Entwicklung von JDK7 auftrat, und die Entwickler haben bei PKware nachgefragt:
https://blogs.oracle.com/xuemingshen/entry/is_zipinput_outputstream_handling_of
Recht weit unten auf der Seite sieht man, dass die Antwort ist, dass "data descriptor" nicht gleichzeitig mit dem "zip64 extended information field" verwenden soll.
....

Der korrekte CRC-Wert für jede Datei steht übrigens (auch, in meinem Fall nur) im "central directory header".

Also Streaming ist noch nicht möglich mit zip64. Und korrekte CRC-Feld, Komprimierte Größe und unkomprimierte Größe muss im Local Header und im "central directory header" stehen.

Siehe auch:

Code: Select all

      4.3.9.5 An extensible data descriptor will be released in a 
      future version of this APPNOTE.  This new record is intended to
      resolve conflicts with the use of this record going forward,
      and to provide better support for streamed file processing.