Eu tenho dois arquivos, um que eu produzi com o zip 2.3.1 e o outro que eu produzi com o zip 3.0. Ambos são um zip do mesmo diretório. Aqui estão os dois arquivos e seus tamanhos:
1.7G from-2.3.1.zip
1.7G from-3.0.zip
Meu plano é fazer a transição do meu sistema para o novo zip, para que eu possa potencialmente criar arquivos zip maiores, como até 3 GB ou mais.
No entanto, minha preocupação é que quando eu descompacte esses arquivos, com uma versão um pouco mais antiga do unzip, recebo erros quando tento descompactar o zip criado com o 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)
$
A razão que eu estou preocupado, é que parece que se eu passar para o zip 3.0, eu vou forçar meus usuários downstream a atualizar para uma versão mais nova do unzip, já que o unzip 6.0, por exemplo, descompacta ambos os arquivos sem erro.
Esta anomalia não ocorre em todos os casos, por isso não tenho a certeza da sua extensão total.
Alguma sugestão? Eu de alguma forma eu construí incorretamente o zip 3.0?
Obrigado.
A diferença é o formato de arquivo Zip64 , que foi introduzido para poder comprimir arquivos maiores. Utilitários mais antigos (como o File Explorer do Windows XP) não entendem isso.
No que diz respeito ao Linux, o Debian Stable incluiu unzip 6.0 desde pelo menos seu lançamento de 2011 (o changelog diz que zip 3.0a foi lançado em 2004 e unzip 6.00 foi lançado em 2009) opinião pessoal é que, se você está "forçando" seus usuários a atualizar, você está fazendo um favor a eles.
Tags compression