CRC-Fehler beim Entpacken von ZIP / Owncloud

[ghisler(Author)]

2white
Das stimmt so nicht, siehe mein Quote oben:

For ZIP64(tm) format archives, the compressed and uncompressed sizes are 8 bytes each."

D.h. wenn im local header ein x64-header vorhanden ist, dann ist die data descriptor ebenfalls 64-bit.

2McNetic
Auch wenn die Spezifikation nicht 100% klar ist - was spricht dagegen, den data descriptor anzuhängen? Die Programme, welche ihn ignorieren, werden weiterhin laufen - und die Programme, die sich streng an die Vorgaben halten wie TC, werden die Dateien entpacken können.

[white]

2white
Das stimmt so nicht, siehe mein Quote oben:

For ZIP64(tm) format archives, the compressed and uncompressed sizes are 8 bytes each."

Ach so. Dann ist die Frage, wie werden diese 8 Bytes gespeichert? Ich denke, mit Hilfe der 0xFFFFFFFF Wert in der Data Descriptor, und "Extra-Feld" 0x0001 nachdem die Data Descriptor. Sonst wäre es nicht abwärtskompatibel sein.

D.h. wenn im local header ein x64-header vorhanden ist, dann ist die data descriptor ebenfalls 64-bit.

Nicht möglich. Siehe:

To address your question, you would not use the Data Descriptor (presence is signaled using bit 3) at the same time as the ZIP64 Extended Information Extra Field (which uses the 0xFFFFFFFF value and "Extra Field" 0x0001). When using the Data Descriptor, the values would be written as ZERO. When alternatively, the ZIP64 extended information extra field is used, the values should be 0xFFFFFFFF.

[white]

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

Als Workaround können Sie den Ordner in der Zip-Datei auf dem gleichen Namen umzubenennen. TC ist dann in der Lage die Datei zu entpacken.

[ghisler(Author)]

To address your question, you would not use the Data Descriptor (presence is signaled using bit 3) at the same time as the ZIP64 Extended Information Extra Field (which uses the 0xFFFFFFFF value and "Extra Field" 0x0001). When using the Data Descriptor, the values would be written as ZERO. When alternatively, the ZIP64 extended information extra field is used, the values should be 0xFFFFFFFF.

Ich sehe da keinen Widerspruch: Die Werte im normalen Header sind 0xFFFFFFFF, woraufhin man im ZIP64 extended header schaut. Dort steht dann wiederum 0 drin, worauf man im Data Descriptor schaut.

[white]

To address your question, you would not use the Data Descriptor (presence is signaled using bit 3) at the same time as the ZIP64 Extended Information Extra Field (which uses the 0xFFFFFFFF value and "Extra Field" 0x0001). When using the Data Descriptor, the values would be written as ZERO. When alternatively, the ZIP64 extended information extra field is used, the values should be 0xFFFFFFFF.

Ich sehe da keinen Widerspruch: Die Werte im normalen Header sind 0xFFFFFFFF, woraufhin man im ZIP64 extended header schaut. Dort steht dann wiederum 0 drin, worauf man im Data Descriptor schaut.

Nicht Er sagt, daß ist nicht möglich..

Wenn man Bit 3 setzt, dann muß crc-32, Komprimierte Größe und unkomprimierte Größe null sein.

Wenn Bit 3 gesetzt ist, werden Software-Programme wahrscheinlich nicht in den Felder Komprimierte Größe und unkomprimierte Größe im Header schauen.

[ghisler(Author)]

Hmm, wieso hat er dann bit 3 gesetzt und die Grössen alle auf FFFFFFFF gestellt?

[McNetic]

Sorry, dass es so lange gedauert hat - manchmal hat das Leben ja noch andere Anforderungen . Und nochmal sorry, dass ich so überzeugend das Problem von mir gewiesen habe - tatsächlich habt ihr Recht, dass das Bit 3 gesetzt war, der Data Descriptor aber fehlte.
In der aktuellen Entwicklungsversion der Zip-Erweiterung, die owncloud nutzt, ist es nun so implementiert, dass der Data Descriptor vorhanden ist und entweder 32Bit- oder 64Bit-Werte enthält, je nach dem, ob die Zip64-Erweiterung aktiv ist. Bis das in Owncloud ankommt, kann aber noch ein wenig Zeit vergehen.

[ghisler(Author)]

Das wäre super, TC kommt mit beiden Typen data descriptor zurecht! wichtig ist für ihn nur der CRC32-Wert, und der ist in beiden Fällen 4 Bytes lang.

[McNetic]

Wobei ich nicht ganz verstehe, warum man überhaupt den Data Descriptor verwendet. Im central directory stehen ja auch alle Daten, und das muss man sowieso zuerst einlesen, um die Offsets der Dateien zu haben. Oder sehe ich das falsch?

[ghisler(Author)]

Nein, muss man nicht unbedingt - TC kann ZIP-Dateien auch ohne Central Directory entpacken. Die Idee des Data Descriptors ist das Streamen: Nicht nur beim Senden kann die Datei so linear von Anfang bis Ende geschrieben werden, auch beim Lesen kann sie linear ohne Sprünge gelesen werden.

[McNetic]

Das verstehe ich nicht so ganz. Beim Senden macht der data descriptor ja noch (in Grenzen) Sinn, da man die Größe der Datei erst nach dem kompletten Schreiben kennt und sie dann da hin schreiben kann (wobei man die auch ins Central Directory schreibt). Beim Empfangen muss ich aber doch vorher wissen, wie lang die Datei ist, sonst weiss ich doch gar nicht, wo die Datei aufhört und der data descriptor anfängt? D.h. aus meiner Sicht schliesst sich das gegenseitig aus.

[ghisler(Author)]

Nein, muss man nicht - wenn die Datei gepackt ist, ergibt sich das Ende aus dem gepackten Code selbst (Ende-Zeichen). Wenn sie ungepackt gespeichert ist, kann (und muss!) man die Grösse im Header speichern.

[Gem]

Mittlerweile sollte das Thema (zumindest was die "Probleme" mit dem TC angeht) erledigt sein:

https://github.com/owncloud/core/issues/10001#issuecomment-131005070

[ghisler(Author)]

Ah, das ist erfreulich! In TC9 wird es eine Unterstützung solcher Archive geben. Ich habe sie aber nicht auf TC 8.52 zurück portiert, weil der Fix sehr komplex ist und viele Dateien von TC betrifft: Dazu müssen beim Einlesen die CRC-Quersummen aller Dateien gespeichert und an alle Entpackfunktionen verteilt werden (die Quersumme direkt bei den daten fehlte ja in der ZIP-Datei von Owncloud). Dies betrifft u.a. Funktionen zum Entpacken einzelner und mehrerer Dateien, Dateianzeige, und Verzeichnisse synchronisieren.