Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 146225 - Bogus errors when --to-stdout is used
Bogus errors when --to-stdout is used
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Depends On:
Blocks: 156799
  Show dependency treegraph
Reported: 2005-01-25 22:02 EST by Jonathan Kamens
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-31 09:05:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tar file which exhibits the bug (387.55 KB, application/octet-stream)
2005-01-27 06:50 EST, Jonathan Kamens
no flags Details

  None (edit)
Description Jonathan Kamens 2005-01-25 22:02:35 EST
When I use tar -xvzf /dev/nosst0 --to-stdout >/dev/null 2>&1, I get a
bunch of errors that look like this:

tar: /d/home/jik/.spam-db: Warning: Cannot truncate: Invalid argument

Why's it trying to truncate something on my disk when I'm running in
--to-stdout mode?

I believe that what all the files which show this error have in common
is that they're all sparse.  Note that the archive I'm trying to
extract was created with --sparse.

When I specify on the command line above a single file I want to
extract, I get a bunch of messages like this while tar is reading the

tar: Skipping to next header

I suspect that these messages, too, are related to sparse files in the
Comment 1 Peter Vrabec 2005-01-26 11:07:56 EST
I can't reproduce it and i don't understand where u get that errors,
because "--to-stdout >/dev/null 2>&1" redirects everything(warnings,
errors) to /dev/null.

What version-release of tar u use?
Comment 2 Jonathan Kamens 2005-01-26 11:10:09 EST
Sorry, I was confused, I wasn't using 2>&1, I was using 
2>/tmp/tar.log and seeing the errors in the log file.
I have tar-1.14-4.

Comment 3 Peter Vrabec 2005-01-27 05:32:59 EST
I still have problem to reproduce this bug.

Try this just for make sure sparse files work:
$ echo hello | dd obs=1k seek=50 of=sparseFile1 
0+1 records in
0+1 records out
$ echo hello | dd obs=1k seek=30 of=sparseFile2
0+1 records in
0+1 records out
$ ls
sparseFile1  sparseFile2  tar
$ tar cvzSf foo.tar.gz sparseFile1 sparseFile2
$ tar xvzf foo.tar.gz --to-stdout > log

This is known bug, already fixed in tar-1.15.1-2
$ tar xvzf foo.tar.gz --to-stdout > log sparseFile1
tar: sparseFile2: invalid sparse archive member
tar: Skipping to next header
tar: Error exit delayed from previous errors

$ rpm -qi tar
Name        : tar       Relocations: (not relocatable)
Version     : 1.14      Vendor: Red Hat, Inc.
Release     : 4         Build Date: Mon 11 Oct 2004 01:25:38 PM UTC
Comment 4 Jonathan Kamens 2005-01-27 06:49:24 EST
I will attach a tar file which I just created with "tar czf
/tmp/foo.tar.gz --sparse ~/.spam-db".  It produces the "Cannot
truncate" error when I then subsequently run "tar xzvf /tmp/foo.tar.gz
--to-stdout >/dev/null".
Comment 5 Jonathan Kamens 2005-01-27 06:50:05 EST
Created attachment 110287 [details]
tar file which exhibits the bug
Comment 6 Peter Vrabec 2005-01-27 11:39:32 EST
$ tar xzSvf foo.tar.gz --to-stdout > /dev/null 
tar: home/jik/.spam-db: Warning: Cannot truncate: Invalid argument

It's just the warning. 

Tar tries to truncate /dev/null, because there is a hole at the end of
.spam-db.  /dev/null is not regular file -> truncation is not succesful.

$ tar xzSvf foo.tar.gz --to-stdout > log
Comment 7 Jonathan Kamens 2005-01-27 20:44:32 EST
First of all, it's inaccurate to say that something isn't a bug just
because "It's just the warning."  Tar shouldn't generate a warning
when the user is doing something reasonable.  It should be checking if
stdout is a file and only trying to truncate it if it is.

Second, the bug is actually deeper than just this warning, as
illustrated by the following:

jik:~!1091$ tar xzf /tmp/foo.tar.gz --to-stdout |wc -c
tar: home/jik/.spam-db: Cannot seek to 0: Illegal seek
tar: Error exit delayed from previous errors

In other words, this version of tar won't extract sparse files into
pipes, which is just unacceptable.  It needs to check if the file
descriptor to which it's writing output is a file, and if not, it
needs to know how to fall back on non-sparse mode, i.e., figuring out
how many zeros there are in the sparse blocks and writing them to the
pipe as zeroes.

This is clearly a bug.  Upstream it if you must, but don't claim that
it isn't a bug, please.
Comment 8 Peter Vrabec 2005-01-31 09:05:01 EST
u are right, it's a bug and it has been already upstreamed.


Note You need to log in before you can comment on or make changes to this bug.