Bug 146225 - Bogus errors when --to-stdout is used
Summary: Bogus errors when --to-stdout is used
Alias: None
Product: Fedora
Classification: Fedora
Component: tar   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact:
Depends On:
Blocks: 156799
TreeView+ depends on / blocked
Reported: 2005-01-26 03:02 UTC by Jonathan Kamens
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-31 14:05:01 UTC
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 11:50 UTC, Jonathan Kamens
no flags Details

Description Jonathan Kamens 2005-01-26 03:02:35 UTC
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 16:07:56 UTC
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 16:10:09 UTC
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 10:32:59 UTC
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 11:49:24 UTC
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 11:50:05 UTC
Created attachment 110287 [details]
tar file which exhibits the bug

Comment 6 Peter Vrabec 2005-01-27 16:39:32 UTC
$ 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-28 01:44:32 UTC
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 14:05:01 UTC
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.