Início / unix / Perguntas / 438368
Accepted
kevbonham
Asked: 2018-04-18 10:26:23 +0800 CST

A descompactação do Unix está falhando, mas o Mac Archive Utility funciona

  • 772

Eu tenho um monte de arquivos com uma .zipextensão que não consigo extrair no meu HPC:

$ unzip RowlandMetaG_part1.zip
Archive:  RowlandMetaG_part1.zip
warning [RowlandMetaG_part1.zip]:  13082642473 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [RowlandMetaG_part1.zip]:  start of central directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)

O tamanho do arquivo zip em si é 17377631766 bytes.

No entanto, quando faço o download do arquivo para o meu mac e clico duas vezes, o aplicativo Archive Utility é capaz de descompactar o arquivo (ele contém um diretório com cerca de 200 arquivos gzipados dentro).

O local que gerou o arquivo diz:

Os arquivos são simplesmente compactados aqui em nosso PC de laboratório local executando o Windows e, em seguida, enviados para o Dropbox... a maioria das pessoas não tem nenhum problema com eles e muitos podem baixar diretamente os links que forneço usando o comando Linux wget diretamente em seus servidores , em seguida, descompacte lá (o utilitário Linux geralmente pode lidar com arquivos compactados no PC).

Não tenho certeza se o fato de os arquivos serem do dropbox é relevante, mas eu costumava curl -LObaixar (também tentei wget- isso não muda nada), e os arquivos aparecem com ?dl=1no final do nome do arquivo. Dito isso, quando faço o download do dropbox para o meu mac, unzipainda falha com o mesmo erro.

Minha pergunta - existe alguma maneira de descompactar isso no servidor? Algum software que realizará a mesma coisa que Archive Utility.app faz ou alguma outra maneira de determinar qual protocolo de descompactação usar?

EDIT: Com base nos comentários: algumas informações adicionais:

$ file RowlandMetaG_part1.zip
RowlandMetaG_part3.zip: Zip archive data, at least v2.0 to extract
$ zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

Além disso, tentei tar, mas sem sucesso.

$ tar -xvf RowlandMetaG_part1.zip
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains `l@\022\t1\fjp\024uP\020' where numeric off_t value expected
tar: Archive contains `\024\311\032b\234\254\006\031' where numeric mode_t value expected
tar: Archive contains `\312\005hЈ\2138vÃ\032p' where numeric time_t value expected
# etc...

E acabo com uma porcaria no diretório assim:

$ ls
???MK??%b???mv?}??????@*??TZ?S?? ??????+??}n>,!???ӟw~?i?(??5?#?ʳ??z0?[?Ed?@?쑱??lT?d???A??T???H??
,??Y??:???'w,??+?ԌU??Wwxm???e~??ZJ]y??ˤ??4?SX?=y$Ʌ{N\?P}x~~?T?3????y?????'
zip archive

5 respostas

  1. Existe a possibilidade de que, embora o arquivo termine com ".zip", não seja um arquivo zip.

    Você pode confirmar se este é um arquivo zip (e ao mesmo tempo determinar qual é o formato real do arquivo) usando o fileutilitário:

    file RowlandMetaG_part1.zip

    Uma vez determinado o formato do arquivo, você pode usar a ferramenta adequada para desarquivá-lo.

    • 4
  2. Best Answer

    Acontece que, como o arquivo é muito grande, zipnão dá para lidar com isso (ele atinge o máximo de 2 Gb). Em vez disso, posso usar jar:

    $ jar xvf RowlandMetaG_part1.zip
inflated: RowlandMetaG_part1/296E-7-26-17-O_S23_L001_R1_001.fastq.gz
# etc...
    • 4

  3. Tente extraí-lo com o utilitário tar, talvez

    tar xvf <file-name>

    Talvez este link seja relevante:

    https://apple.stackexchange.com/questions/208139/how-to-deal-with-unzip-error-on-a-large-file-in-osx

    • 0

  4. Já me deparei com o mesmo problema e ainda não consegui resolver. Se eu fizer isso, atualizarei esta resposta.

    No entanto, para esclarecer algumas coisas:

    Você pode acreditar no OP de que o arquivo é um arquivo zip.

    O "problema" que a ferramenta de descompactação do Linux parece ter é que o arquivo não possui um diretório central no final, mas precisa ser descompactado sequencialmente, e a ferramenta do Linux parece não conseguir fazer isso.

    Em teoria, a zipferramenta deve ser capaz de corrigir isso, com a -FFopção de verificar o arquivo sequencialmente e criar um novo arquivo zip a partir dele. Acontece, no entanto, que isso não funciona com zips grandes (> 4 GB) - ele cria outro arquivo zip ilegível, sem o diretório central no final.

    Contexto: O formato de arquivo PKZIP armazena as informações sobre cada item arquivado em dois locais: uma vez antes de cada fluxo compactado (isso é obrigatório, embora as informações de comprimento possam estar incorretas) e outra no final de uma lista de todos os itens armazenados e este é meio que opcional (bem, sempre deve haver um por definição do padrão, mas também permite um fallback passando pelas entradas iniciais, o que a ferramenta zip da Apple aparentemente faz).

    Depois de mais algumas análises do problema, acredito que o problema seja o seguinte:

    • O arquivo zip foi escrito pelo comando ditto, que é uma versão ligeiramente modificada do zip, embora eu não conheça os detalhes.
    • O arquivo zip em questão não está usando o formato zip64.
    • O cabeçalho do arquivo local para o arquivo muito grande contém um tamanho inválido (2^32-1). Isso é o que confunde a ferramenta de descompactação.
    • O valor CRC do cabeçalho do arquivo local é zero.
    • O Utilitário de arquivo da Apple pode descompactar este arquivo porque ignora o tamanho incorreto do arquivo no cabeçalho local e, em vez disso, descompacta o fluxo até que o fluxo sinalize seu fim (fluxos gzip compactados têm um marcador de fim de fluxo).
    • 0

  5. Adicionando uma observação de que, no meu caso, tar/jar falhou, mas 7zip ajudou (7z x big.zip). A discussão de arquivos grandes me apontou para esta pergunta útil na pilha da Apple, como lidar com o erro de descompactação em um arquivo grande no OSX?

    • 0

relate perguntas