Bug 146225 - Bogus errors when --to-stdout is used
Summary: Bogus errors when --to-stdout is used
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tar
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact:
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2005-01-31 14:05:01 UTC
Type: ---
Embargoed:


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
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 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.

  jik

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
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 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 
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-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
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 14:05:01 UTC
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.