Bug/Inkompatibilität des internen zip-Entpackers

[algol]

Hallo zusammen, bin da gerade auf ein merkwürdiges Problem gestossen, das jedoch anscheinend nichts mit dem neuen 8.52_rc1 zu tun hat, sondern auch schon mit 8.51a_final bestanden haben dürfte.

Anlässlich eines geplanten OS-upgrades meines Android-Smartphones (Galaxy Note 4) habe ich von SamMobile die passende Lollipop-Firmware als zip-Datei heruntergeladen. Sie ist ca. 1,8 GB gross, die darin enthaltene .tar.md5-Firmware-Datei ca. 3,5 GB.

Ich erwähne das, da mir bekannt ist, dass es bei .zip-Dateien >2 GB eventuell zu Inkompatibilitäten mit manchen Entpackern kommen kann. Die fragliche Archivdatei bleibt mit 1,8 GB jedoch unter dieser Grenze.

Dennoch gab es beim versuchten Entpacken dieser mit dem TC-internen Entpacker Probleme. Der Fortschrittsbalken zeigte zunächst überhaupt keine Aktivität, nach "ewiger Zeit" (1 min 30) zeigte er dann "1%" an, um darauf jede weitere Aktivität einzustellen. Es wurden also niemals 2% erreicht.

Umso überraschender tauchte nach ca. 3 min die "fertig entpackte" Datei im Zielverzeichnis auf, die im Vergleich mit später anders entpackten Versionen jedoch eine längere Sequenz mit korruptem, binär ungleichem Inhalt aufwies.

Da das Phänomen mit 8.52_rc1 erstmalig beobachtet wurde, testete ich kurz, ob es auf einem anderen PC, noch mit 8.51a_final, ebenfalls auftreten würde. Ergebnis: ja, 8.51a_final scheitert auch.

Es erschien mir aber undenkbar, dass ein derartiger, "genereller Bug" die ganze Zeit über unentdeckt geblieben wäre und packte/entpackte daher probeweise eine doppelt so grosse Datei mit dem internen Packer. Wie erwartet funktionierte dies sowohl mit 8.51a_final als auch mit 8.52_rc1.

Der Fehler hat also mit der speziellen .zip-Datei von SamMobile zu tun. Frage daher: hat hier jemand Erfahrung, mit welchem zip-Packer SamMobile seine Firmware-zip-Dateien erzeugt bzw. ob es sich dabei um einen speziellen Typ handelt? Oder hat es vielleicht mit dem ".tar.md5"-Dateiformat der darin enthaltenen Firmware-Datei zu tun, sodass der TC-interne Entpacker darüber "stolpert"?

Zu erwähnen ist jedoch, dass z.B. SpeedCommander und ähnliche Tools keine Probleme mit dem Entpacken dieser speziellen Datei hatten. Und natürlich wäre es deshalb - besonders und gerade wegen der heiklen Natur solcher Firmware-Dateien - dringlich wünschenswert, dass auch der TC-interne zip-Packer mittelfristig damit klar käme.

mfg
algol

[ghisler(Author)]

Das kann passieren, wenn der Packer die Grösse der Datei nicht im Header VOR der Datei speichert - TC kann dann keinen Fortschritt anzeigen, weil er die gepackte Grösse nicht kennt. Diese steht zwar auch im sogenannten "central directory" am Ende des ZIPs, dessen Daten stehen aber wärend des Entpackens leider nicht zur Verfügung.

[algol]

Danke für die prompte Antwort. Das Ganze wäre auch halb so schlimm, wäre da nicht - leider nicht reproduzierbar (bei 2 von geschätzt 10 Versuchen) - eine Passage mit korruptem Inhalt, noch dazu etwa an der gleichen Stelle (nach ca. 1/10 der Dateilänge) aufgetreten.

Ich bin sonst wirklich der letzte, der das "hohe Lied" etwa des "SpeedCommander" singt, IMHO ist TC sonst turmhoch überlegen, aber diese eine Aufgabe des Entpackens dieser besonderen Datei schafft er in etwa der halben Zeit, ohne erkennbare "Hänger" oder Unstetigkeiten und mit kontinuierlich ablaufender Fortschrittsanzeige, währen es in TC von Anbeginn erkennbar "hakt". Geht das Mitbewerbs-produkt (ich vermeide absichtlich den Begriff "Konkurrenz" ) hier einen anderen Weg? Es liefert jedenfalls immer die binär gleiche Datei, was ich wieder nur an Hand des exzellenten file-compare in TC verifizieren kann.

mfg
algol

[Horst.Epp]

Danke für die prompte Antwort. Das Ganze wäre auch halb so schlimm, wäre da nicht - leider nicht reproduzierbar (bei 2 von geschätzt 10 Versuchen) - eine Passage mit korruptem Inhalt, noch dazu etwa an der gleichen Stelle (nach ca. 1/10 der Dateilänge) aufgetreten.

Ich bin sonst wirklich der letzte, der das "hohe Lied" etwa des "SpeedCommander" singt, IMHO ist TC sonst turmhoch überlegen, aber diese eine Aufgabe des Entpackens dieser besonderen Datei schafft er in etwa der halben Zeit, ohne erkennbare "Hänger" oder Unstetigkeiten und mit kontinuierlich ablaufender Fortschrittsanzeige, währen es in TC von Anbeginn erkennbar "hakt". Geht das Mitbewerbs-produkt (ich vermeide absichtlich den Begriff "Konkurrenz" ) hier einen anderen Weg? Es liefert jedenfalls immer die binär gleiche Datei, was ich wieder nur an Hand des exzellenten file-compare in TC verifizieren kann.

mfg
algol

Das kann aber auch ein Hardware Fehler in deinem System sein.
Wenn da ein Fehler im TC ist müsste er eigentlich reproduzierbar sein.
Deine Probleme können sehr wohl auch durch RAM Fehler auftreten welche sich je nach Program Logik und anderen Umständen verschieden auswirken.

[algol]

Das kann aber auch ein Hardware Fehler in deinem System sein.

Natürlich, ausschliessen kann ich zum gegenwärtigen Zeitpunkt gar nichts. Habe auch momentan zu wenig Zeit, das eingehender nachzuverfolgen.

Dagegen spricht aber, dass es auf zumindest 2 Rechnern, wenigstens dem äusseren Anschein nach, gleichartig verläuft (einmal 8.51a, einmal 8.52rc1/final).

mfg
algol

[Horst.Epp]

Das kann aber auch ein Hardware Fehler in deinem System sein.

...
Dagegen spricht aber, dass es auf zumindest 2 Rechnern, wenigstens dem äusseren Anschein nach, gleichartig verläuft (einmal 8.51a, einmal 8.52rc1/final).
mfg
algol

Ok, dann scheidet die Hardware eigentlich aus.

[milo1012]

Gibt es denn einen öffentlich verfügbaren Download-Link zur besagten Datei?
Dann könnte man sich das Ganze mal genauer anschauen.

Ich meine mich zu erinnern auch einige Zip-Dateien gehabt zu haben (APK-Dateien), die ich zunächst als vermeintlich korrupte Dateien ignoriert hatte,
aber die auch reproduzierbar mit (einigen, nicht allen) anderen Entpackern funktionierten.
Könnten mal wieder irgendwelche Nicht-Standard-Erweiterungen seitens der Posix-Zip-Packer sein.

[algol]

Gibt es denn einen öffentlich verfügbaren Download-Link zur besagten Datei?

Ja, gibt es, auch wenn ich nicht verlangen kann, dass andere User meine Probleme lösen. Aber danke für die Bereitschaft, nur muss man zum download dort auch noch angemeldet/registriert sein und die Datei ist eben sehr gross (fast 2 GB) und lädt ausserdem sehr langsam, sofern man dort nicht zahlendes Mitglied ist.

http://www.sammobile.com/firmwares/download/46026/N910FXXU1BOC5_N910FATO1BOC1_ATO/

Aus allen gesammelten Indizien heraus vermute ich aber auch sehr stark, dass es mit dieser speziellen zip-Datei zu tun haben muss, denn, wie gesagt, eine doppelt so grosse Datei, von mir selbst in TC ge-zip-t und danach wieder entpackt, funktioniert dagegen auf beiden PCs klaglos.

Deshalb die Frage an das Forum, ob jemand das genaue zip-Format für Samsung-Firmware vielleicht kennt. Vor Jahren, beim Galaxy Note 1, als gleichartige Dateien noch ca. 1/2 GB gross waren, hat das damals in TC, soweit ich erinnere, ohne Probleme geklappt. Ich werde die Datei auch selbst nochmal über Nacht herunterladen, um eine korrupte Datei auszuschliessen. Aber in dem Fall hätte das Entpacken/CRC-Test mit anderen Entpackern eigentlich auch nicht funktionieren dürfen.

mfg
algol

[ghisler(Author)]

Das Ganze wäre auch halb so schlimm, wäre da nicht - leider nicht reproduzierbar (bei 2 von geschätzt 10 Versuchen) - eine Passage mit korruptem Inhalt, noch dazu etwa an der gleichen Stelle (nach ca. 1/10 der Dateilänge) aufgetreten.

Das dürfte nicht am Entpacker liegen - TC testet bei jedem Entpacken die CRC-Quersumme. Wenn es doch Fehler gibt, dann erst nach dem Entapcken, beim Schreiben auf die Platte.

[knightrider]

@algol
habe mir die zip von SamMobile heruntergeladen
Das unzippen mit dem internen TC-Entpacker hat ohne Probleme funktioniert.
Der Ladebalken läuft nicht mit und das Entpacken dauert länger als mit WinRAR aber ansonsten alles ok.

http://abload.de/img/2015-08-27_132229j3s4f.png

[algol]

Kurzes update: habe über Nacht nochmal die Datei geladen und deren korrekte Übertragung verifiziert (was nach erfolgreichem CRC-check ohnehin so gut wie sicher war). Bei einigen weiteren Entpack-Versuchen mit TC ist seither auch hier kein weiterer Fehlversuch mit "Datensalat" aufgetreten.

Vergleichsweise habe ich auch die letzte beta von 7-Zip ausprobiert. Auch diese entpackt in der halben Zeit und mit kontinuierlichem Fortschrittsbalken (was immer das dort für eine reale Bedeutung hat).

Trotzdem werde ich den Eindruck nicht los, dass TC beim Entpacken irgendwie "hakt" und vielleicht deshalb in Relation so lange braucht. Wenn bei dieser zip-Datei die interne Dateigrösse zunächst unbekannt ist, eröffnet das 3 Fragen:

1. Aus welcher Information leiten die anderen Entpacker deren Fortschrittsbalken ab? Ist das, wie oft bei M$, nur irgendein fake-Laufbalken?
2. Wieso zeigt der TC-Balken nach einer - offenbar unsinnigen - Zeitspanne "1%" Fortschritt an?
3. Woher kennt TC die korrekte, interne Dateigrösse, wenn man, ohne zu entpacken, bloss in das Archiv hineinsieht?

mfg
algol

[ghisler(Author)]

1. TC zeigt den Fortschritt aufgrund der Header-Daten und der gelesenen Daten an. Wenn der Header z.B. 2 GB meldet und 1GB eingelesen wurde, zeigt er 50% an. Wenn im Header aber keine Grösse steht, kann er auch keinen Fortschritt anzeigen.

2. Das kann passieren, wenn es im Archiv mehrere Dateien hat. 1% dürfte bedeuten, dass eine kleinere Datei komplett entpackt wurde.

3. Am zentralen ZIP-Verzeichnis am ENDE der Datei. Allerdings sind das die entpackten Grössen. Für den Fortschrittsbalken ist aber die gepackte Grösse wesentlich.

[algol]

2. Das kann passieren, wenn es im Archiv mehrere Dateien hat. 1% dürfte bedeuten, dass eine kleinere Datei komplett entpackt wurde.
3. Am zentralen ZIP-Verzeichnis am ENDE der Datei. Allerdings sind das die entpackten Grössen. Für den Fortschrittsbalken ist aber die gepackte Grösse wesentlich.

ad 2. in dem betreffenden Archiv gibt es nur die einzige, 3,5GB grosse .tar.md5-Datei, die allerdings ihrerseits wieder ein Archiv ist, das dann mehrere Dateien enthält.

ad 3. Zeigen die anderen Entpacker dann vielleicht das Verhältnis der momentanen, entpackten Grösse während des Entpackens im Verhältnis zu der erwarteten End-Dateigrösse aus dem zentralen ZIP-Verzeichnis als Fortschritt in deren Balken an? Denn irgendwie müssen die das Problem ja anders lösen. Und dann bliebe ja immer noch der beträchtliche Geschwindigkeits-Vorteil der dort verwendeten Methoden, denn einen CRC-check machen die AFAIK auch.

Es geht mir hier keinesfalls ums "Kritisieren", aber ich werde den Verdacht nicht los, dass das Entpack-Verfahren in TC, mal ganz abgesehen von der fehlenden/irreführenden Fortschrittsanzeige, bei dieser speziellen Datei irgendwie "hakt", was natürlich das Vertrauen in das entpackte Endprodukt beim Benutzer nicht gerade steigert.

mfg
algol

[algol]

Nachtrag zum beobachteten, seltsamen Verhalten des zip-Entpackers:

Im Rahmen meiner Tests zum Entpacken einer einzigen, ca. 3,5 Gbyte grossen Datei aus einem zip-Archiv mit nicht funktionierender Fortschrittsanzeige habe ich auch mehrfach die Option "Test Archives" <Alt-Shift-F9> benützt.

Frage: ist es eigentlich normal und gewollt, dass diese Operation im (vermutlichen) Erfolgsfall sang- und klanglos und ohne jeden Kommentar ausläuft bzw. abbricht? Wie ich inzwischen festgestellt habe, hat das auch gar nichts mit besagter, grosser Datei mit vermutlich fehlender header-Information zu tun, sonder tritt bei allen, auch kleinen Archiven beliebigen Typs auf.

Eigentlich hätte ich nach erfolgreichem Archiv-Test irgendeine Meldung, etwa ein pop-up-Fenster mit "CRC-Check OK" oder ähnliches erwartet.

mfg
algol

[ghisler(Author)]

Ja, wenn kein Fehler auftritt, gibt es auch keine Meldung. Man erkennt ja am Fortschrittsdialog, dass der Test durchgelaufen ist. Muss man viele ZIP-Dateien testen, wäre es mühsam, bei jeder zu bestätigen, dass sie OK ist (und die meisten sind ja OK).