Date: Fri, 31 Oct 2014 16:55:55 +0100 From: <rank1seeker@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: tar behavior 9.* -> 10.* Message-ID: <20141031165555.000048ec@gmail.com> In-Reply-To: <1414764305.17308.190.camel@revolution.hippie.lan> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> <1414676160.17308.151.camel@revolution.hippie.lan> <20141031134201.00000127@gmail.com> <1414764305.17308.190.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Oct 2014 08:05:05 -0600 Ian Lepore <ian@FreeBSD.org> wrote: > On Fri, 2014-10-31 at 13:42 +0100, rank1seeker@gmail.com wrote: > > On Thu, 30 Oct 2014 07:36:00 -0600 > > Ian Lepore <ian@FreeBSD.org> 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 <allanjude@freebsd.org> 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 > I see ..., sounds like a "feature or a bug?" Ok, I agree with this fix. Thanks for explanation. Domagoj
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141031165555.000048ec>