Re: svn commit: r199066 - head/usr.bin/gzip

Xin LI <delphij_at_delphij.net> writes:

> Xin LI wrote:
>> Xin LI wrote:
>>> Anonymous wrote:
>>>> Xin LI <delphij_at_FreeBSD.org> writes:
>>>>> Author: delphij
>>>>> Date: Mon Nov  9 02:37:02 2009
>>>>> New Revision: 199066
>>>>> URL: http://svn.freebsd.org/changeset/base/199066
>>>>>
>>>>> Log:
>>>>>   Apply a NetBSD fix (revision 1.12) to handle multi-session bzip2 files
>>>>>   as created by pbzip2.
>>>>>   
>>>>>   Submitted by:	mrg (NetBSD.org)
>>>>>   MFC after:	1 week
>>>>>
>>>>> Modified:
>>>>>   head/usr.bin/gzip/unbzip2.c
>>>>>
>>>>     $ touch blah
>>>>     $ bzip2 blah
>>>>     $ gzip -d blah.bz2
>>>>     gzip: read: No such file or directory
>>>>     Exit 2
>>>> Regression? Can you reproduce?
>>> Yes, this is a regression (confirmed that this behavior is different
>>> from bzip2 and a regression from 199065).  Thanks for your report and
>>> I'll investigate what's happening.
>> 
>> I think the attached patch should fixed this issue.  Could you please test?
>
> The previous fix has introduced an issue that revealed another bug as
> well (gzip -d -c can't decompress large-ish input stream, i.e. something
> like bzip2 -c ObsoleteFiles.inc | gunzip -d -c).  The proposed patch:

Tested your last patch. No longer able to reproduce the issue.

>
>  * Set end_of_file flag if we hit a short read.  This usually saves one
> read after the actual end of file.
>  * Only bail out when BZ_OK and end_of_file and no output is given from
> decompression engine.  This would fix the streaming issue.
>  * Use maybe_errx() instead of maybe_err - We don't have a valid errno
> at hand at the point we have received BZ_OK, and make the information
> more meaningful.