Date: Thu, 30 Oct 2014 07:36:00 -0600 From: Ian Lepore <ian@FreeBSD.org> To: rank1seeker@gmail.com Cc: freebsd-hackers@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: tar behavior 9.* -> 10.* Message-ID: <1414676160.17308.151.camel@revolution.hippie.lan> In-Reply-To: <20141030133230.00004204@gmail.com> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > With your code situation is same. > > To cut it short, this is a non critical bug fixed in 9.*, aka tar > regression.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1414676160.17308.151.camel>