Bug 146225 - Bogus errors when --to-stdout is used
Bogus errors when --to-stdout is used
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
rawhide
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:
Environment:
Last Closed: 2005-01-31 09:05:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
archive:

tar: Skipping to next header

I suspect that these messages, too, are related to sparse files in the
archive.
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.

  jik
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
sparseFile1
sparseFile2
$ tar xvzf foo.tar.gz --to-stdout > log
sparseFile1
sparseFile2

This is known bug, already fixed in tar-1.15.1-2
$ tar xvzf foo.tar.gz --to-stdout > log sparseFile1
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 
home/jik/.spam-db
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
home/jik/.spam-db
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
0

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
Sorry, 
u are right, it's a bug and it has been already upstreamed.

http://lists.gnu.org/archive/html/bug-tar/2003-08/msg00024.html


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