I am going crazy with a gzip file.

I can decompress the file in Windows using WinRAR but it is impossible on any UNIX operating system.

the file seems to be ok. If I do

file the_name_of_the_file.gz

I get:

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

But if I do

gunzip -f the_name_of_the_file.gz

I alsways get:

gzip: the_name_of_the_file.gz: unexpected end of file

The same problem happens when I try to extract the file using the GUI tool in Ubuntu or MacOSX,

Any ideas?

  • Is it the same exact file (i.e. You have it on a flash drive and have opened it up from the two operating systems) or are you downloading it individually? If the later, you could have an incomplete download that doesn't have all of the data (aka, corrupt). – Freesnöw May 4 '11 at 18:56
  • 1
    The file command won't check all of the file. It'll just look at a few bytes in the header to figure out that it's a gz encoded file. – James C May 4 '11 at 19:00
  • It is not corrupted because I have tried first in Unix and later in Windows. – cues7a May 4 '11 at 19:00
  • Did you make the gzip file? If so, what operating system and application did you use to create the gzip file? – Sun May 24 '16 at 21:03

A workaround for uncompressing a file when gzip fails with "unexpected end of file" is to use zcat (also usually provided by the gzip package of your distribution).

$ zcat file.raw.gz > file.raw

| improve this answer | |

Did you by any chance transfer the file from Win* to Unix via ftp in ascii mode? That may explain it. Is the file the same size on Win* and Unix?

| improve this answer | |
  • I have tried tu decompress the file first in Windows and later in Unix. – cues7a May 4 '11 at 19:02

I suspect you're corrupting the file when copying it to the *nix machine.

FTP it in binary mode.

| improve this answer | |
  • I think the file is not corrupted because I tried to gunzip it fist in unix and later in Windows. – cues7a May 4 '11 at 19:01
  • 1
    What you are saying makes no sense. If you didn't need to create a copy of the file, then say so. If you did, maybe your copying process (FTP?) was incorrect. – Robin Green May 4 '11 at 19:11
  • I transfered the file via USB pendrive. I tried first in UNIX and it didn't work and then I tried in Windows and it worked. – cues7a May 4 '11 at 19:33

I've solved the problem using the utility P7zip, a port of 7za.exe for POSIX systems.

| improve this answer | |
  • So, you're saying the archived file used a compression method that is not recognized by legacy Unix tools? – Sun May 24 '16 at 21:03

Based on a few experiences with WinRar, my first guess is that it's extracting incomplete or corrupted files without giving an error, while gzip is (correctly) giving an error.

What does 7zip make of your file?

What version does gzip -V announce?

What does gzip -t the_name_of_the_file.gz tell you? (probably the same unexpected EOF, but worth a try)

| improve this answer | |
  • gzip -V: gzip 1.3.12,, gzip -t the_name_of_the_file -> unexpected EOF – cues7a May 5 '11 at 6:49

I had the same problem and, in my case, it was due to the fact that the file was an empty (0 bytes) gz file, created with the touch command:

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

gzip could not decompress it, when called with the command:

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

The correct way to represent an empty txt file would have been generating first the txt file, then compress it and, finally, decompress it:

$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

I don't know if this scenario represents your case, but it may give you some clue or help somebody else.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.