From owner-freebsd-current@FreeBSD.ORG Sat Nov 14 04:53:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D661065672; Sat, 14 Nov 2009 04:53:03 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id AE0488FC15; Sat, 14 Nov 2009 04:53:02 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1093707eyd.9 for ; Fri, 13 Nov 2009 20:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=pD2koJSpR8pPg0gxuThA5tJ2Px+opC8/uWPKp8+iZf4=; b=TLoJ6PU4rj0blJf87hwZGHQp/VxsvEP/yAnQkwU6LT4OFsgq7QrNPmiwzQgPSM3MzM sbuic4IKGXS0lyhJB+3HfmB9yR4NnEtu/3wcGkJLCx0STzH+1L4X6xnp7NzY2/A57sK+ Y5814btZEOP2tc9/gm5Gvcdx3sqzfnb/UHRfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=VAsXx1TCEfRz0/7M6ZA9uwyojQqFtHmDrgKaHIOToMcrCpgfOLwhIib7kxdEHvpOB3 BbJkWfxhQbXjpQJtooYR72/Dmllq7rMMssdJVJPrGkxbuioY3yP4PMkbhrq8jjAXgURl e9mJhWuKGs9hK2porz7kxwyeeBG1bo8bAwRgA= Received: by 10.213.23.146 with SMTP id r18mr600808ebb.46.1258174381656; Fri, 13 Nov 2009 20:53:01 -0800 (PST) Received: from localhost (95-24-85-117.broadband.corbina.ru [95.24.85.117]) by mx.google.com with ESMTPS id 28sm1753076eyg.30.2009.11.13.20.52.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Nov 2009 20:53:00 -0800 (PST) From: Anonymous To: d@delphij.net References: <200911090237.nA92b2m7005471__19254.880565177$1257734275$gmane$org@svn.freebsd.org> <867htvhygy.fsf@gmail.com> <4AFDDEA1.70900@delphij.net> <4AFDE27F.1070406@delphij.net> <4AFDEB70.5080807@delphij.net> Date: Sat, 14 Nov 2009 07:52:58 +0300 In-Reply-To: <4AFDEB70.5080807@delphij.net> (Xin LI's message of "Fri, 13 Nov 2009 15:27:44 -0800") Message-ID: <86zl6pg11x.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.ORG, Xin LI , matthew green Subject: Re: svn commit: r199066 - head/usr.bin/gzip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 04:53:03 -0000 Xin LI writes: > Xin LI wrote: >> Xin LI wrote: >>> Anonymous wrote: >>>> Xin LI 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.