GNU bug report logs - #49952
new snapshot available: gzip-1.10.34-aa73

Previous Next

Full log

Message #36 received at 49952 <at> debbugs.gnu.org (full text, mbox):

From: "Adler, Mark" <madler <at> alumni.caltech.edu>
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
Cc: "49952 <at> debbugs.gnu.org" <49952 <at> debbugs.gnu.org>,
 Stephen Kitt <steve <at> sk2.org>
Subject: Re: bug#49952: new snapshot available: gzip-1.10.34-aa73
Date: Tue, 10 Aug 2021 16:09:06 +0000

Seems like too extreme of a behavior change. If this proposal is implemented, then 99.9% of the time, pigz -l will decode the entire file. If someone is regularly doing pigz -l on a large number of files, the time it would take would go up orders of magnitude.

The fundamental dilemma is that gzip -l and pigz -l give the correct answer nearly all of the time, and is extremely fast. So “-l" still seems useful.

> On Aug 9, 2021, at 2:41 PM, Paul Eggert <eggert <at> CS.UCLA.EDU> wrote:
> 
> On 8/9/21 8:19 AM, Adler, Mark wrote:
>> pigz -l doesn’t do that, but pigz -lt does. Since -t has to decode the whole file, -l combined with it will use that information to give the correct result. For compatibility, pigz -l still does what gzip does, which is to guess based on what it finds at the end of the file.
> 
> Perhaps gzip -l could do bounded work, as follows:
> 
> * Look at the header to see what its byte count B says.
> 
> * Decompress until it sees more than B bytes.
> 
> * If so, report that the -l sizes are bogus. If not, carry on as before.
> 
> Due to format limits, B can be at most 2**32 - 1, so this provides a bound on the amount of work, a bound that's reasonably small nowadays.

Previous Next

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