GNU bug report logs - #45148
Piping into gzip --list -

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#45148: closed (Piping into gzip --list -)
Date: Tue, 29 Mar 2022 23:16:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 29 Mar 2022 16:15:38 -0700
with message-id <b515a240-0e41-4344-575a-58ba94f02549 <at> cs.ucla.edu>
and subject line Re: Piping into gzip --list -
has caused the debbugs.gnu.org bug report #45148,
regarding Piping into gzip --list -
to be marked as done.

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


-- 
45148: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45148
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefano Marsili <efanomars <at> gmx.ch>
To: bug-gzip <at> gnu.org
Subject: Piping into gzip --list -
Date: Wed, 9 Dec 2020 20:05:50 +0100

[Message part 3 (text/plain, inline)]

Hi,
I wanted to help the Debian project and found the gzip bug report

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575884

Despite not being a C programmer I decided to give it a try.
Since this is the first time I have a patch for an open source project,
I thought that maybe I should first ask upstream if it makes sense.

In the code of gzip.c there is the comment:

 * If the lseek fails, we could use read() to get to the end, but
 * --list is used to get quick results.
 * Use "gunzip < foo.gz | wc -c" to get the uncompressed size if
 * you are not concerned about speed.

Assuming it is correct, the patch does just that, use read() to get
to the end.
After applying the patch and running

  $ time cat rnd0.bin.gz | gzip -l -

on a gzipped 3GB file created with /dev/urandom, the result is

   compressed        uncompressed  ratio uncompressed_name
   3000485948          3000000000  -0.0% stdout

   real   0m0.740s
   user   0m0.013s
   sys    0m1.134s

To me it seems quite fast, but maybe gzip is used with much bigger
files and one second is too slow.

The patch is attached to this e-mail.
I'd like to know what you think about it.
Thanks
 
 

[pipetolist.diff (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefano Marsili <efanomars <at> gmx.ch>
Cc: 45148-done <at> debbugs.gnu.org
Subject: Re: Piping into gzip --list -
Date: Tue, 29 Mar 2022 16:15:38 -0700

Thanks for your bug report dated 2020-12-09. As it happens I was fixing 
a related bug that is commonly reported, and the patch I installed 
happened to fix your bug in a different way. The patch I installed is here:

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

and something like this should appear in the next gzip release.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.