zip 3.0 не имеет обратной совместимости с zip 2.3.1?
У меня есть два файла, один из которых я создал с помощью zip 2.3.1, а другой - с zip 3.0. Оба почтовых индекса одного и того же каталога. Вот два файла и их размеры:
1.7G from-2.3.1.zip
1.7G from-3.0.zip
Мой план состоит в том, чтобы перевести мою систему на новый zip-файл, чтобы я мог потенциально создавать большие zip-файлы, например, до 3 ГБ или около того.
Тем не менее, меня беспокоит то, что когда я распаковываю эти файлы, с немного более старой версией распаковки, я получаю ошибки, когда пытаюсь распаковать архив, созданный с помощью zip 3.0.
$ unzip -t from-2.3.1.zip > /dev/null # NO Errors
$ unzip -t from-3.0.zip > /dev/null
warning [from-3.0.zip]: 76 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [from-3.0.zip]: reported length of central directory is
-76 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
error: expected central file header signature not found (file #67358).
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
$
Меня беспокоит то, что если я перейду на zip 3.0, то заставлю всех своих нижестоящих пользователей обновить все до новой версии unzip, так как, например, unzip 6.0, разархивирует оба этих файла без ошибок.
Эта аномалия встречается не во всех случаях, поэтому я не уверен в ее полной степени.
Какие-либо предложения? Неужели я как-то неправильно собрал zip 3.0?
Благодарю.
1 ответ
Разница заключается в формате файла Zip64, который был введен для сжатия больших файлов. Старые утилиты (такие как Проводник Windows XP) не понимают этого.
Что касается Linux, Debian Stable включен unzip 6.0
по крайней мере, его выпуск 2011 года (журнал изменений говорит zip 3.0a
был выпущен в 2004 году и unzip 6.00
был выпущен в 2009 году), поэтому, по моему личному мнению, если вы "заставляете" своих пользователей обновляться, вы делаете им одолжение.