svn commit: r199066 - head/usr.bin/gzip
Anonymous
swell.k at gmail.com
Sat Nov 14 04:53:03 UTC 2009
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.
More information about the freebsd-current
mailing list