Bug 146225
| Summary: | Bogus errors when --to-stdout is used | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Kamens <jik> | ||||
| Component: | tar | Assignee: | Peter Vrabec <pvrabec> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-01-31 14:05:01 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 156799 | ||||||
| Attachments: |
|
||||||
|
Description
Jonathan Kamens
2005-01-26 03:02:35 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? 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 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 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". Created attachment 110287 [details]
tar file which exhibits the bug
$ 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 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. 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 |