emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52227: closed (gzip bug: gzip -l produces bad ratio)


From: GNU bug Tracking System
Subject: bug#52227: closed (gzip bug: gzip -l produces bad ratio)
Date: Thu, 16 Dec 2021 02:34:03 +0000

Your message dated Wed, 15 Dec 2021 18:33:12 -0800
with message-id <b546014b-f19b-8025-cd7b-2266676b41d9@cs.ucla.edu>
and subject line Re: bug#17804: RFC: fixing the 32-bit size and time limits in 
gzip file format
has caused the debbugs.gnu.org bug report #17804,
regarding gzip bug: gzip -l produces bad ratio
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
17804: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17804
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: gzip bug: gzip -l produces bad ratio Date: Wed, 1 Dec 2021 08:43:55 -0800
Description of bug:  "gzip -l" produces the following output:

gzip -l big_archive.tgz
         compressed        uncompressed  ratio uncompressed_name
       617736021001          3613347840 -16995.9% big_archive.tar

As you can see, the ratio field is producing an incorrect result.  I'm not sure if this is because the archive is too big or what.  It was generated via the following command in quotes:
"tar -cv /path/to/folder/big_folder | gzip --rsyncable > /path/to/big_archive.tgz"

gzip version: 1.9
Hardware: Dell R720 Poweredge Rack Server
OS: Debian 10 buster
Kernel: Linux 4.19.0-18-amd64
Architecture:
x86-64

Best regards,
--

G. Austin Corbett, P.E.
Staff Engineer
OurEvolution Energy & Engineering

1821 Buttermilk Lane
Arcata, CA 95521
Mobile: 707.845.4778

--- End Message ---
--- Begin Message --- Subject: Re: bug#17804: RFC: fixing the 32-bit size and time limits in gzip file format Date: Wed, 15 Dec 2021 18:33:12 -0800 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1
On 6/18/14 15:12, Paul Eggert wrote:
One simple way forward would be to implement what pigz -tl does, namely, decompress the input stream and discard the output, but print its size.

I finally got around to implementing that suggestion:

https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=cf26200380585019e927fe3cf5c0ecb7c8b3ef14
https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=32fef43b442c7abc70414863d64718cd06f6477a

So I am closing this old bug report.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]