Home > Archive > Compression > November 2004 > gzip 1.3.5 (winxp) negative ratio on file > 4GB
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gzip 1.3.5 (winxp) negative ratio on file > 4GB
|
|
|
| i used gzip 1.3.5 to zip a 4.2 GB db file for ftp transfer. now when I:
gzip -l file.gz
i get a negative compression ratio (-946.3%) but the
gzip -t file.gz
comes back with no problems
is this normal for > 4GB files?
| |
| Eric Bodden 2004-11-23, 3:55 pm |
| On 23 Nov 2004 08:01:24 -0800, Compy wrote:
> is this normal for > 4GB files?
Yes, since 2^32 = 4294967296. So as long as you don't wanna use a 64bit
machine and/or other custom data types this is normal.
Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
How to remove incorrectly marked bad secotrs on NTFS...
http://bodden.de/misc/ntfsrecovery/
| |
| Mark Adler 2004-11-24, 3:55 pm |
| Eric Bodden <newsserver_mails@bodden.de> wrote in message news:<3aujxvp6h0yj.1trq3x4jaznth.dlg@40tude.net>...
> On 23 Nov 2004 08:01:24 -0800, Compy wrote:
>
> Yes, since 2^32 = 4294967296. So as long as you don't wanna use a 64bit
> machine and/or other custom data types this is normal.
Actually, this has nothing to do with 64-bit machines or custom data
types. It has to do with the fact that the gzip format only stores
the low four bytes of the uncompressed file length (i.e. modulo 2^32)
at the end of the gzip file, and so the problem is inescapable
regardless of what data types are used to make the computation. The
gzip -l command tries to use the length of the gzip file and the
stored uncompressed length to compute the percentage compression.
However there is no way for it to tell, without decompressing the
whole file, what the actual uncompressed length is if it was >= 2^32.
mark
|
|
|
|
|