Tester l'intégrité du fichier ZIP?

Autant que je sache, l'option zip -T détermine uniquement si les fichiers peuvent être extraits - elle ne teste pas vraiment l'intégrité de l'archive. Par exemple, j'ai délibérément corrompu le CRC local (pas le répertoire central) pour un fichier, et zip ne s'en souciait pas du tout, signalant que l'archive était OK. Existe-t-il un autre utilitaire pour le faire?

Il y a beaucoup de redondance interne dans les fichiers ZIP, et ce serait bien d'avoir un moyen de tout vérifier. Bien sûr, normalement, le répertoire central est tout ce dont vous avez besoin, mais lors de la réparation d'une archive corrompue, tout ce que vous avez est souvent un fragment, avec le répertoire central encombré ou manquant. Je voudrais savoir si les archives que je crée sont aussi récupérables que possible.

décompressez -t

Testez les fichiers d'archive.

Cette option extrait chaque fichier spécifié en mémoire et compare le CRC (contrôle de redondance cyclique, une somme de contrôle améliorée) du fichier développé avec la valeur CRC stockée de l'original.

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

Tenter de réparer une archive comparera les CRC locaux et centraux, et la combiner avec des tests d'archives permettra de vérifier tous les CRC. Si vous courez

unzip -t archive.zip

et

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

et ni l'un ni l'autre ne se plaignent, cela signifie que le contenu de l'archive correspond à la fois aux CRC central et local. (Vous pouvez supprimer archivefix.zipensuite.)

Pour vérifier cela, en commençant par le code source Info-ZIP pour zip3.0, j'ai créé un fichier comme suit:

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

J'ai ensuite corrompu le répertoire central CRC pour zip.txten modifiant l'octet à l'offset 0xB137. J'ai eu le comportement opposé à ce que vous avez observé; unzip -va rapporté le CRC modifié à partir du répertoire central, mais unzip -tet a zip -Tindiqué que le dossier était OK (vérification contre le CRC local).

Mais courir

zip -F test --out testfix

signalé

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

Le fichier "corrigé" répertorie toujours le CRC modifié pour zip.txt.

La modification du CRC local pour le zip.txtdécalage 0x10 a causé les deux unzip -tet zip -Tpour signaler une erreur CRC, mais zip -Fn'a rien détecté de mal.

Ainsi, d'après mes expériences, les décalages entre le contenu d'une entrée d'archive et ses CRC peuvent être détectés comme suit:

• local uniquement: zip -Tet unzip -t; zip -Fse plaindra également de l'inadéquation local-central
• local et central: zip -Tetunzip -t
• central uniquement: zip -Tet unzip -tne se plaindra pas, mais zip -Findiquera un décalage local-central

(Notez que par défaut zip -Tutilise simplement unzip -tqq, so zip -Tet unzip -tvraiment sont équivalents. Vous pouvez lire le unzipcode source pour vérifier que tester une archive compare vraiment le CRC local, pas le central; recherchez extract_or_test_files(), extract_or_test_entrylist()et extract_or_test_member(), le tout extract.c.)