--- Begin Message ---
Subject: |
Truncated size of big file |
Date: |
Tue, 31 Oct 2017 20:59:33 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
Before decompressing a copy of database I've decided to take a look at
it's size:
localhost stg # gunzip -l SWHTOROLT_20171019.GBK.gz
compressed uncompressed ratio uncompressed_name
3645968323 1782666240 -104.5% SWHTOROLT_20171019.GBK
uncompressed is reported as 1.7Gb which is definitely something unreal
like -104.5 compress ratio
Actual size after unzip is:
localhost stg # gunzip SWHTOROLT_20171019.GBK.gz
localhost stg # ls -l SWHTOROLT_20171019.GBK
-rw-r--r-- 1 root root 18962535424 Oct 19 15:59 SWHTOROLT_20171019.GBK
Lickily I've had enough disk space - but let me not attach problematic
archive to email, I suppose it's easier to reproduce this locally ;)
Alex.
--- 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 ---