Erreur sur les octets supplémentaires lors de la décompression d'un fichier

28

Quand j'entre unzip ../founation-latest.zip, il sort ceci:

avertissement [../foundation-latest.zip]: 248 octets supplémentaires au début ou dans le fichier zip (tentative de traitement quand même)

Le fichier est de 138 Ko. Il se décompresse correctement, mais pourquoi ai-je cette erreur?

zip

— eau de pluie11
source

2

Une cause possible est que, dans une étape de son parcours sur votre système, il a été transféré ftpen mode ASCII plutôt qu'en mode BINAIRE et certains octets ont été ajoutés. Si vous l'avez utilisé ftpà n'importe quel stade, exécutez-le à ftpnouveau, en utilisant la commande «bin» avant tout «put» ou «get».

— Mark Plotnick

Il pourrait avoir une charge utile malveillante au début. C'est un Internet hostile. Faites attention à l'utilitaire de décompression que vous utilisez pour ouvrir un zip comme ça.

— jbrahy

Il y a beaucoup de conjectures dans les réponses actuelles, car il existe de nombreuses causes possibles. Il serait utile d'avoir un lien ou une copie du fichier en question.

— duozmo

Concernant la charge utile supplémentaire potentiellement malveillante: à cette taille, vous pouvez télécharger le fichier sur virustotal.com pour le faire vérifier - au cas où il n'y aurait aucune information personnelle. Cependant, je ne m'inquiéterais pas trop des virus sous Linux, uniquement si vous copiez le fichier d'origine ailleurs. (Vous pouvez toujours

— reconditionner

Juste pour confirmer que c'est un problème. J'ai essayé de créer une sauvegarde de mon espace de fichiers iTunes avec zipet avec ditto. Le unzipfourni (par 10.11) a échoué avec les deux, ainsi qu'avec 7za. MacOS décompresse n'aime tout simplement pas (gros?) Les fichiers zip.

— Otheus

37

Mon problème était parce que j'essayais d'utiliser "décompresser" sur MAC OSX qui ne peut pas gérer les choses compressées avec PKZIP.

J'ai pu brew install p7zipdécompresser et utiliser la commande 7za x some_file.zip.

J'ai à l'origine trouvé la solution dans cet article: need-pk-compat-v4-5-can-do-v2-1

— duyker
source

4

J'ai téléchargé une machine virtuelle Windows sur microsoft.com et c'était la solution pour décompresser.

— sod

1

Cela peut également s'appliquer à la décompression sous Linux (dans mon cas: UnZip 6.00 du 20 avril 2009, par Debian.)

— BradHards

2

Il convient également de mentionner qu'il est un peu plus rapide et montre des progrès.

— previous_developer

P7z gère également les fichiers plus volumineux et les fichiers avec un zip plus récent

— Konrads

Même problème aujourd'hui sur une image AWS linux. Téléchargé le RPM p7zip à partir de timeoff.wsisiz.edu.pl/rpms.html et l'archive testée et extraite sans problème.

— pignons

23

J'ai trouvé ce fil qui avait un problème similaire. Le rapport de bogue est intitulé: la décompression échoue sur 5,4 Go de ZIP avec "octets supplémentaires au début ou dans le fichier zip" . L'un des correctifs suggérés consistait à utiliser cette commande dans le .zipfichier.

$ zip -FFv foo.zip --out fixed.zip

Exemple d'exécution

$ zip -FFv foo.zip --out fixed.zip
Fix archive (-FF) - salvage what can
 Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
 Local ( 1      0): copying: d1/f1   (651734 bytes)
 Local ( 1 651817): copying: d1/d2/  (0 bytes)
 Local ( 1 651905): copying: d1/d2/f3   (80 bytes)
 Local ( 1 652083): copying: d1/f23   (891 bytes)
 Local ( 1 653021): copying: d1/f27   (8764 bytes)
 Local ( 1 661837): copying: d1/f24   (14818 bytes)
 Local ( 1 676709): copying: d1/f25   (17295 bytes)
...
 Cen   ( 1 5488799949): updating: d1/f13
 Cen   ( 1 5488800052): updating: d1/f14
Zip64 EOCDR found ( 1 5488800155)...
Zip64 EOCDL found ( 1 5488800211)...
EOCDR found ( 1 5488800231)...
$ echo $?
0

commutateur -FF de zip

extrait de la page man zip

       -FF
       --fixfix
              Fix the zip archive. The -F option can be used if some 
              portions of the archive are missing, but requires a reasonably 
              intact central directory.   The  input  archive is scanned as 
              usual, but zip will ignore some problems.  The resulting 
              archive should be valid, but any inconsistent entries will be 
              left out.

              When doubled as in -FF, the archive is scanned from the 
              beginning and zip scans  for  special  signatures  to  
              identify  the  limits between the archive members. The single 
              -F is more reliable if the archive is not too much damaged, so 
              try this option first.

              If  the archive is too damaged or the end has been truncated, 
              you must use -FF.  This is a change from zip 2.32, where the 
              -F option is able to read a truncated archive.  The -F option 
              now more reliably fixes archives with minor damage and the -FF 
              option is  needed to fix archives where -F might have been 
              sufficient before.
              ...

— slm
source

3

J'ai déjà vu ce type d'erreur lors du transfert de l'archive zip via un service Web qui rencontrait des problèmes. Lors de l'examen direct du fichier zip, j'ai trouvé qu'un message d'erreur du service Web avait été envoyé devant le fichier zip.

Vous pouvez essayer d'examiner le fichier zip sous forme de texte et voir si quelque chose d'intéressant apparaît à l'avant.

— Michael Kohne
source

3

Je viens d'avoir cet avertissement aussi. Dans mon cas, cela a été causé par le téléchargement avec 'curl -i' qui a fait apparaître les en-têtes http au début du fichier zip. que je suis bête. Bien sûr, ce ne sera pas la cause / solution dans tous les cas, mais peut-être que cela aide quelqu'un ...

— dknaus
source

2

Il peut s'agir d'une archive auto-extractible (windows .exe) ou a été complétée pour une raison quelconque.

— Ricky Beam
source

1

Qu'entendez-vous par "rembourré"?

— rainwater11

Octets supplémentaires (généralement null (zéro)) pour donner au fichier une longueur spécifique. Auparavant, c'était un artefact de la taille du bloc de transfert de fichiers (par exemple, xmodem), mais dans le monde moderne, cela ne se produit pas. Il peut également s'agir d'une signature cryptographique. (Je n'ai pas le fichier, donc je ne sais pas ce que sont ces 248 octets.)

— Ricky Beam

0

J'ai également eu le même problème. J'ai observé le problème lorsque j'ai copié des fichiers de Windows vers le serveur Unix sans utiliser le mode bin. La meilleure façon de résoudre le problème était de transférer les fichiers en mode bin.

— Amit
source

(1) Ces informations ont déjà été présentées dans un commentaire . C'est bon, mais… (2) le commentaire contient des informations plus détaillées que cette réponse. (3) Vous devriez améliorer cette réponse en décrivant de quoi vous parlez. Veuillez ne pas répondre dans les commentaires; modifiez votre réponse pour la rendre plus claire et plus complète.

— Scott

0

J'ai eu le même problème sous Linux avec un .zipfichier de plus de 4 Go, aggravé par une only DEFLATED entries can have EXT descriptorerreur.

La commande a cependant 7z xrésolu tous mes problèmes.

Attention cependant, la commande 7z xextraira tous les fichiers avec un chemin enraciné dans le répertoire courant. L'option -opermet de spécifier un répertoire de sortie.

— Serge Stroobandt
source