Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227523 - Unpacking compressed archive fails when STDOUT is closed
Summary: Unpacking compressed archive fails when STDOUT is closed
Alias: None
Product: Fedora
Classification: Fedora
Component: tar
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lukas Vrabel
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-06 17:14 UTC by Jan "Yenya" Kasprzak
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-04 12:41:55 UTC

Attachments (Terms of Use)
patch is fixing this issue for tar 1.15.1 (deleted)
2007-02-09 15:41 UTC, Lukas Vrabel
no flags Details | Diff

Description Jan "Yenya" Kasprzak 2007-02-06 17:14:10 UTC
Description of problem:
When tar is started with STDOUT closed, it fails to unpack the gzipped archive,
because of a bug in tar.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create a gzipped tar archive, named "file.tar.gz"
2. run "tar xf" with stdout closed ("tar xf file.tar.gz >&-" in bash syntax)
Actual results:
gzip: stdout: Bad file descriptor
tar: Child returned status 1
tar: Error in writing to standard output
tar: Error is not recoverable: exiting now

Expected results:
tar archive should be correctly unpacked regardless of file descriptor setup

Additional info:
I have found this problem when running tar from mod_perl script under Apache2 -
Apache does not keep the file descriptors 0, 1, and 2 set up for its children.
So external commands may occasionally run with stdout or stdin closed.

running "strace -f -o /tmp/strace.out -- tar xf file.tar.gz" revealed what tar
does when spawning the "gzip -d" child:

- after fork(), the tar child process has "file.tar.gz" opened as filedescriptor
#1, and the output side of the pipe to its parent as filedescriptor #3. Before
exec()ing "gzip -d", the child does the following:

// switch the pipe to fd #1:
close(1); // oops, we have lost our compressed input file :-(
dup(3); // duplicates the write side of the pipe to fd#1
close(3); // get rid of the old pipe descriptor
// now switch the input stream to fd #0 (but at this point, we
// don't have the compressed file opened anymore)
dup(1); // but it duplicates the write side of the pipe instead
// after we exec "gzip -dc", it does not have fd #1 opened

I suggest that tar should explicitly check whether it has filedescriptors 0 and
1 opened, and also that it use dup2() instead of dup().

Comment 1 Lukas Vrabel 2007-02-08 13:24:59 UTC
it's fixed in upstream 1.16.1

Comment 2 Jan "Yenya" Kasprzak 2007-02-08 13:29:19 UTC
Thanks, will you issue a new package for FC6, or should I create my own
upstream-based package?

Comment 3 Jan "Yenya" Kasprzak 2007-02-08 13:38:42 UTC
BTW, this bug is also in RHEL4 (tar-1.14-12.RHEL4).

Comment 4 Lukas Vrabel 2007-02-08 13:51:43 UTC
for more info on 1.16.1 see bug no 226917:

Comment 5 Jan "Yenya" Kasprzak 2007-02-08 14:25:10 UTC
works for me (I had to install m4 and autoconf from -devel to compile it, though).

Comment 6 Lukas Vrabel 2007-02-09 15:41:29 UTC
Created attachment 147781 [details]
patch is fixing this issue for tar 1.15.1

run automake after applying patch

Comment 7 Fedora Update System 2007-04-12 19:42:44 UTC
tar-1.15.1-25.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

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