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):
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)
gzip: stdout: Bad file descriptor
tar: Child returned status 1
tar: Error in writing to standard output
tar: Error is not recoverable: exiting now
tar archive should be correctly unpacked regardless of file descriptor setup
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().
it's fixed in upstream 1.16.1
Thanks, will you issue a new package for FC6, or should I create my own
BTW, this bug is also in RHEL4 (tar-1.14-12.RHEL4).
for more info on 1.16.1 see bug no 226917: http://bugzilla.redhat.com/bugzilla/
works for me (I had to install m4 and autoconf from -devel to compile it, though).
Created attachment 147781 [details]
patch is fixing this issue for tar 1.15.1
run automake after applying patch
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.