it-swarm.com.de

Integrität der Zip-Datei testen?

Soweit ich das beurteilen kann, bestimmt die Option Zip -T nur, ob Dateien extrahiert werden können - sie testet das Archiv nicht wirklich auf interne Integrität. Zum Beispiel habe ich den lokalen CRC (nicht das zentrale Verzeichnis) für eine Datei absichtlich beschädigt, und Zip war das überhaupt egal, da das Archiv als OK gemeldet wurde. Gibt es ein anderes Dienstprogramm, um dies zu tun?

Es gibt eine Menge interner Redundanz in Zip-Dateien, und es wäre schön, eine Möglichkeit zu haben, alles zu überprüfen. Normalerweise ist das zentrale Verzeichnis alles, was Sie brauchen, aber wenn Sie ein beschädigtes Archiv reparieren, haben Sie oft nur ein Fragment, wobei das zentrale Verzeichnis überfüllt ist oder fehlt. Ich würde gerne wissen, ob von mir erstellte Archive so wiederherstellbar wie möglich sind.

23
Marc Rochkind

entpacke -t

Testen Sie 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 ]

22
Theophrastus

Wenn Sie versuchen, ein Archiv zu reparieren, werden die lokalen und zentralen CRCs verglichen. Wenn Sie dies mit Archivtests kombinieren, können alle CRCs überprüft werden. Wenn du läufst

unzip -t archive.Zip

nd

Zip -F archive.Zip --out archivefix.Zip

und keiner beschwert sich, das heißt, der Inhalt des Archivs stimmt sowohl mit den zentralen als auch mit den lokalen CRCs überein. (Sie können anschließend archivefix.Zip Löschen.)

Um dies zu überprüfen, habe ich ausgehend vom Info-Zip-Quellcode für Zip 3.0 eine Datei wie folgt erstellt:

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

Ich habe dann das zentrale Verzeichnis CRC für Zip.txt Beschädigt, indem ich das Byte am Offset 0xB137 geändert habe. Ich habe das Gegenteil von dem, was Sie beobachtet haben. unzip -v Hat die geänderte CRC aus dem zentralen Verzeichnis gemeldet, aber unzip -t Und Zip -T Haben gemeldet, dass die Datei in Ordnung ist (Überprüfung mit der lokalen 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 wurde weiterhin die geänderte CRC für Zip.txt Aufgeführt.

Das Ändern der lokalen CRC für Zip.txt Bei Offset 0x10 führte dazu, dass sowohl unzip -t Als auch Zip -T Einen CRC-Fehler meldeten, aber Zip -F Hat nichts Falsches festgestellt.

So können aus meinen Experimenten Fehlanpassungen zwischen dem Inhalt eines Archiveintrags und seinen CRCs wie folgt erkannt werden:

  • nur lokal: Zip -T und unzip -t; Zip -F Beschwert sich auch über die lokal-zentrale Nichtübereinstimmung
  • lokal und zentral: Zip -T und unzip -t
  • nur zentral: Zip -T und unzip -t beschweren sich nicht, aber Zip -F zeigt eine lokal-zentrale Nichtübereinstimmung an

(Beachten Sie, dass Zip -T Standardmäßig einfach unzip -tqq Verwendet, sodass Zip -T Und unzip -t Wirklich gleichwertig sind. Sie können den Quellcode unzip lesen Um zu überprüfen, ob das Testen eines Archivs wirklich die lokale CRC vergleicht, nicht die zentrale, suchen Sie nach extract_or_test_files(), extract_or_test_entrylist() und extract_or_test_member(), alle in extract.c.)

12
Stephen Kitt