Inesperado final de archivo. Archivo comprimido Gzip

16

Me estoy volviendo loco con un archivo gzip.

Puedo descomprimir el archivo en Windows usando WinRAR pero es imposible en cualquier sistema operativo UNIX.

El archivo parece estar bien. Si lo hago

file the_name_of_the_file.gz

Yo obtengo:

the_name_of_the_file.gz: gzip compressed data, from Unix, last modified: Sun Jan 30 14:10:21 2011

Pero si lo hago

gunzip -f the_name_of_the_file.gz

Siempre obtengo:

gzip: the_name_of_the_file.gz: unexpected end of file

El mismo problema ocurre cuando intento extraer el archivo usando la herramienta GUI en Ubuntu o MacOSX,

¿Algunas ideas?

linux bash gzip

— cues7a
fuente

¿Es el mismo archivo exacto (es decir, lo tiene en una unidad flash y lo ha abierto desde los dos sistemas operativos) o lo está descargando individualmente? Si es más tarde, podría tener una descarga incompleta que no tiene todos los datos (también conocidos como corruptos).

— Freesnöw

1

El filecomando no verificará todo el archivo. Solo mirará unos pocos bytes en el encabezado para descubrir que es un gzarchivo codificado.

No está dañado porque lo intenté primero en Unix y luego en Windows.

— cues7a

¿Hiciste el archivo gzip? Si es así, ¿qué sistema operativo y aplicación usó para crear el archivo gzip?

— Dom

5

Se gzipdebe usar una solución alternativa para descomprimir un archivo cuando falla con el "final inesperado del archivo" zcat(generalmente también proporcionado por el paquete gzip de su distribución).

$ zcat file.raw.gz > file.raw

— gangelop
fuente

2

¿Por casualidad transfirió el archivo de Win * a Unix a través de ftp en modo ascii? Eso puede explicarlo. ¿Es el archivo del mismo tamaño en Win * y Unix?

— Heiko Rupp
fuente

He intentado descomprimir el archivo primero en Windows y luego en Unix.

— cues7a

1

Sospecho que está corrompiendo el archivo al copiarlo en la máquina * nix.

FTP en modo binario.

— Brian Roach
fuente

Creo que el archivo no está dañado porque traté de comprimirlo en unix y luego en Windows.

— cues7a

1

Lo que estás diciendo no tiene sentido. Si no necesita crear una copia del archivo, dígalo. Si lo hizo, tal vez su proceso de copia (FTP?) Fue incorrecto.

— Robin Green

Transferí el archivo a través de USB pendrive. Lo intenté primero en UNIX y no funcionó y luego lo intenté en Windows y funcionó.

— cues7a

1

He resuelto el problema utilizando la utilidad P7zip , un puerto de 7za.exe para sistemas POSIX.

— cues7a
fuente

Entonces, ¿estás diciendo que el archivo archivado usó un método de compresión que no es reconocido por las herramientas de Unix heredadas?

— Dom

0

Basado en algunas experiencias con WinRar, mi primera suposición es que está extrayendo archivos incompletos o corruptos sin dar un error, mientras que gzip está (correctamente) dando un error.

Que hace 7zip de su archivo?

Que versión hace gzip -V anuncia?

Que gzip -t the_name_of_the_file.gzte dice (probablemente el mismo EOF inesperado, pero vale la pena intentarlo)

— Jason Sherman
fuente

gzip -V: gzip 1.3.12 ,, gzip -t the_name_of_the_file -> EOF inesperado

— cues7a

0

Tuve el mismo problema y, en mi caso, se debió al hecho de que el archivo era un archivo vacío (0 bytes) gz, creado con el touchcomando:

$touch file.txt.gz
-rw-r--r-- 1 user user    0 2016-05-24 11:48 file.txt

gzip no pudo descomprimirlo cuando se lo llamó con el comando:

$gzip -dv file.txt.gz
gzip: file.txt.gz: unexpected end of file

La forma correcta de representar un txtarchivo vacío habría sido generar primero el txtarchivo, luego comprimirlo y, finalmente, descomprimirlo:

$touch file.txt

$gzip -v file.txt
file.txt:         0.0% -- replaced with file.txt.gz

$gzip -dv file.txt.gz
file.txt.gz:      0.0% -- replaced with file.txt

No sé si este escenario representa su caso, pero puede darle alguna pista o ayudar a alguien más.

— Alfredo Capobianchi
fuente