Помилка зайвих байтів при розпакуванні файлу

Коли я входжу unzip ../founation-latest.zip, він видає це:

попередження [../foundation-latest.zip]: 248 додаткових байтів на початку або в zipfile (спроба все-таки обробити)

Файл - 138 КБ. Він розпаковується правильно, але чому я отримую цю помилку?

Моя проблема полягала в тому, що я намагався використовувати "розпакувати" на MAC OSX, який не може впоратися з елементами, зіштовхуваними PKZIP.

Мені вдалося brew install p7zipскасувати розпакування за допомогою команди 7za x some_file.zip.

Я спочатку знайшов рішення в цій статті: need-pk-compat-v4-5-can-do-v2-1

Я знайшов цю тему, яка мала подібну проблему. Звіт про помилку має назву: unzip не вдається на ZIP в 5,4 ГБ з "додатковими байтами на початку або в zipfile" . Одним із запропонованих виправлень було використання цієї команди у .zipфайлі.

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

Приклад Виконати

$ 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

zip -FF перемикач

уривок зі сторінки zip man

       -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.
              ...

Я вже бачив подібний тип помилок, коли передавався zip-архів через веб-сервіс, який мав проблеми. Після безпосереднього вивчення zip-файлу, я виявив, що повідомлення про помилку від веб-служби було надіслано перед поштовим файлом.

Ви можете спробувати вивчити поштовий файл як текст і побачити, чи з’являється щось цікаве спереду.

Просто було це попередження. У моєму випадку це було викликано завантаженням його з 'curl -i', що спричинило появу заголовків http на початку ZIP-файлу. дурний мене. Напевно, це не буде причиною / рішенням у всіх випадках, але, можливо, це комусь допоможе ...

Це може бути архів, що самозаймається (windows .exe), або з якихось причин.

У мене теж було таке питання. Я спостерігав за проблемою, коли я копіював файли з Windows на сервер Unix, не використовуючи режим bin. Найкращим способом вирішити проблему було перенесення файлів у бін-режимі.

У мене була така ж проблема в Linux з .zipфайлом, більшим за 4 Гб, з only DEFLATED entries can have EXT descriptorпомилкою.

Команда 7z xвирішила всі мої проблеми.

Але будьте обережні, команда 7z xбуде витягувати всі файли з корінням, корінням до поточного каталогу. Цей параметр -oдозволяє вказати вихідний каталог.