tar behavior 9.* -> 10.*

[Ian Lepore]

On Fri, 2014-10-31 at 13:42 +0100, rank1seeker at gmail.com wrote:
> On Thu, 30 Oct 2014 07:36:00 -0600
> Ian Lepore <ian at FreeBSD.org> wrote:
> 
> > On Thu, 2014-10-30 at 13:32 +0100, rank1seeker at gmail.com wrote:
> > > On Fri, 24 Oct 2014 10:43:33 -0400
> > > Allan Jude <allanjude at freebsd.org> wrote:
> > > 
> > > > On 2014-10-24 08:15, rank1seeker at 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