From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 14:05:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05E09CC3; Fri, 31 Oct 2014 14:05:15 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC8E06D6; Fri, 31 Oct 2014 14:05:14 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkCp9-000McP-Bv; Fri, 31 Oct 2014 14:05:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9VE562m085237; Fri, 31 Oct 2014 08:05:06 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+H5bm1wuVhTPdWKPVAj6Dh X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: tar behavior 9.* -> 10.* From: Ian Lepore To: rank1seeker@gmail.com In-Reply-To: <20141031134201.00000127@gmail.com> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> <1414676160.17308.151.camel@revolution.hippie.lan> <20141031134201.00000127@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Oct 2014 08:05:05 -0600 Message-ID: <1414764305.17308.190.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:05:15 -0000 On Fri, 2014-10-31 at 13:42 +0100, rank1seeker@gmail.com wrote: > On Thu, 30 Oct 2014 07:36:00 -0600 > Ian Lepore wrote: > > > On Thu, 2014-10-30 at 13:32 +0100, rank1seeker@gmail.com wrote: > > > On Fri, 24 Oct 2014 10:43:33 -0400 > > > Allan Jude wrote: > > > > > > > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > > > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > > > > > > > Bug? > > > > > _______________________________________________ > > > > > > > What happens if you pipe it to something that doesn't close the > > > > pipe prematurely > > > > > > > > try: > > > > > > > > tar ... | cat - > > > > > > > > It makes sense that it throws an error when you pipe to head, > > > > which then closes the pipe before the file has finished being > > > > written. > > > > > > > > > > Even in it's "cleanest form" it hangs: > > > # tar -xOf src.txz usr/src/UPDATING > > > Outputed complete content immidieatly to STDOUT and then hanged for > > > 56 seconds! > > > > > > > This is a completely different case, not at all related to what you > > reported earlier. It is doing exactly what it is supposed to. With > > the arguments you gave it, it must scan (and thus decompress) the > > entire archive, because there could be a newer version of UPDATING > > later in the archive (think tar --append). If you want it to quit as > > soon as it has found the first copy of usr/src/UPDATING, add -q (or > > --fast-read). > > > > -- Ian > > > Thank you Ian. > It did a trick. However, if you've looked at a link, you would see I've > reported 2 issues of which 1 is now solved. > > It is tar's pipe problem, which started to occur in 10.* > # tar -qxOf src.txz usr/src/UPDATING | head > ... expected output ... > ./usr/src/UPDATING: Write error > tar: Error exit delayed from previous errors. > > Exits with 1 (fail) > When it comes to the original report, if anything I'd be inclined to say the old behavior was buggy and now it works right. It used to ignore some output errors and now it doesn't. If you were restoring a backup rather than browsing a readme, you'd certainly want to know that it failed to write some of the output. -- Ian