Integrität der ZIP-Datei testen?

Fast kann ich sagen, dass die Option zip -T nur bestimmt, ob Dateien extrahiert werden können - sie testet das Archiv nicht wirklich auf interne Integrität. Zum Beispiel habe ich absichtlich den lokalen CRC (nicht das zentrale Verzeichnis) für eine Datei beschädigt, und zip hat sich überhaupt nicht darum gekümmert. Das Archiv wurde als OK gemeldet. Gibt es ein anderes Dienstprogramm, um dies zu tun?

ZIP-Dateien weisen eine Menge interner Redundanz auf, und es wäre schön, wenn Sie alles überprüfen könnten. Normalerweise ist das zentrale Verzeichnis alles, was Sie brauchen, aber bei der Reparatur eines beschädigten Archivs ist häufig nur ein Fragment vorhanden, bei dem das zentrale Verzeichnis überfüllt ist oder fehlt. Ich möchte wissen, ob die von mir erstellten Archive so wiederherstellbar wie möglich sind.

-t entpacken

Testen Sie die Archivdateien.

Diese Option extrahiert jede angegebene Datei im Speicher und vergleicht die CRC (zyklische Redundanzprüfung, eine erweiterte Prüfsumme) der erweiterten Datei mit dem gespeicherten CRC-Wert des Originals.

[Quelle: https://linux.die.net/man/1/unzip ]

Beim Versuch, ein Archiv zu reparieren, werden die lokalen und zentralen CRCs verglichen, und wenn dies mit Archivtests kombiniert wird, können alle CRCs überprüft werden. Wenn du läufst

unzip -t archive.zip

und

zip -F archive.zip --out archivefix.zip

und beklagen Sie sich auch nicht, das heißt, der Inhalt des Archivs stimmt sowohl mit dem zentralen als auch mit dem lokalen CRC überein. (Sie können archivefix.zipdanach löschen .)

Um dies zu überprüfen zip, habe ich beginnend mit dem Info-ZIP-Quellcode für 3.0 eine Datei wie folgt erstellt:

zip -9 test.zip zip.txt zipup.c

Ich habe dann das zentrale CRC-Verzeichnis beschädigt, zip.txtindem ich das Byte bei Offset 0xB137 geändert habe. Ich habe das Gegenteil von dem, was Sie beobachtet haben; unzip -vmeldete die geänderte CRC aus dem zentralen Verzeichnis, aber unzip -tund zip -Tmeldete, dass die Datei in Ordnung war (Prüfung gegen die lokale CRC).

Aber rennen

zip -F test --out testfix

berichtet

Fix archive (-F) - assume mostly intact archive
Zip entry offsets do not need adjusting
 copying: zip.txt
        zip warning: Local Entry CRC does not match CD: zip.txt
 copying: zipup.c

In der "korrigierten" Datei ist weiterhin die geänderte CRC für aufgeführt zip.txt.

Das Ändern des lokalen CRC für zip.txtbei Offset 0x10 verursachte beide unzip -tund zip -Teinen CRC - Fehler zu berichten, aber zip -Fnichts falsch erkennen.

Aufgrund meiner Experimente können also Abweichungen zwischen den Inhalten eines Archiveintrags und seinen CRCs wie folgt festgestellt werden:

• nur lokal: zip -Tund unzip -t; zip -Fwird sich auch über die lokal-zentrale Fehlpaarung beschweren
• lokal und zentral: zip -Tundunzip -t
• Nur zentral: zip -Tund unzip -tbeschwert sich nicht, weist jedoch zip -Fauf eine lokal-zentrale Nichtübereinstimmung hin

(Beachten Sie, dass standardmäßig zip -Tverwendet einfach unzip -tqq, so zip -Tund unzip -twirklich gleichwertig sind Sie das lesen können. unzipQuellcode überprüfen, ob ein Archiv Prüfung vergleicht wirklich die lokale CRC, nicht die mittlere, sucht extract_or_test_files(), extract_or_test_entrylist()und extract_or_test_member(), alles in extract.c.)