Why not solve it? (long-term) The GZIP format supports optional attributes.
One attribute could be a 'wrap counter' (as per RADIUS approach to >4Gb sessions). David. -----Original Message----- From: Drew Scott Daniels [mailto:[EMAIL PROTECTED] Sent: Wed 06-Jul-05 02:16 To: David Luyer; [EMAIL PROTECTED] Subject: Re: Bug#316183: Incorrect compression ratio in gzip -l for large files On Wed, Jun 29, 2005 at 10:37:47AM +1000, David Luyer wrote: > Package: gzip > Version: 1.3.5-11 > > It looks like gzip is storing the incorrect filesize for large > files (probably only 32bits of it). Here's a roughly 40GiB file > (or at least a tar file of 39GiB of files) compressed to roughly 2.6GiB. > > [EMAIL PROTECTED]:~/acct-archive-log# gzip -l acct-log-to-20050227.tar.gz > compressed uncompressed ratio uncompressed_name > 2605966699 61474816 -4139.1% > acct-log-to-20050227.tar > > If the file size is too large to store in the bits available maybe it > should be stored as '-1' so gzip -l will be consistent with other > formats it doesn't know the uncompressed size of? > This is a known and documented problem. Perhaps rather than closing it this time, it should be marked wontfix. Drew Daniels
