Hide Forgot
Description of problem: When try to create an tar.Z file it fails. Version-Release number of selected component (if applicable): ncompress-4.2.4-54.el6.x86_64 tar-1.23-3.el6.x86_64 How reproducible: Every time when I try to create an archive. Steps to Reproduce: 1. run tar -c -Z -f /tmp/test.tar.Z /foo Actual results: It fails with: tar: Child returned status 2 tar: Error is not recoverable: exiting now Expected results: That my files are packed into /tmp/test.tar.Z Additional info: Try to build an tar.gz or tar.bz2 will work.
Could you please rerun it with -vv options? Tar is using compress external program here, and from compress(1) manpage you could see that exit code 2 means that the compressed output is larger than the input (this is ncompress specific thing, therefore bzip2/gzip just works)... I could easily reproduce that when trying to use -Z on .xz archive... tar -cZvvf test.tar.Z t1lib-coverity-wall.tar.xz -rw-rw-r-- Reset/Reset 38828 2011-05-09 19:26 t1lib-coverity-wall.tar.xz tar: Child returned status 2 tar: Error is not recoverable: exiting now However, in other cases, it works just fine. [Reset@dhcp-24-196 ~]$ tar -cZf test.tar.Z tmp [Reset@dhcp-24-196 ~]$ ls test.tar.Z test.tar.Z [Reset@dhcp-24-196 ~]$ tar tZf test.tar.Z | wc -l 3517 As this is ncompress behaviour and expected behaviour, it could likely be not a bug. Anyway, the exit code 2 is from child process, therefore tar is most probably innocent here, so moving to ncompress. And if confirmed, it probably should be closed notabug.
Yes I can reproduce it. It is some confusing. You get an error, but the file is created, and file /tmp/test.tar.Z says, that it is compressed. I think, it will be better when tar don't speak about an error on return code 2 when compress is used. Because at compress(1) return code 1 is only an error as I read.
I know that this is reproducible, but not "every time", I was just asking if my suspection about "compress program not able to compress further" was correct. The result is compress(1) archive - but it contains some/all uncompressed files. But because of compress(1) header, it has to be processed by uncompress(1), to get the content back. You wrote: "How reproducible: Every time when I try to create an archive." And on my machine I'm able to create archive compressed by ncompress with no errors. Therefore the needinfo was set... To be honest, ncompress is legacy program with last official release ~5 years ago and this behaviour is expected from it. My recommendation is to use different tar backends for archiving nowadays. Of course, tar could ignore this type of errors in the case of ncompress, but this will be definitely nasty part of the code (as in other cases child exit 2 means serious issues).
In the production environment I have change from compress to bzp2. So in case that nobody care about the ncompress code, I think it will be ok, to mark this report as errata with the comment to switch to new tar backends. To the "How reproducible" I mean, I have try 2 or 3 directory's to tar. And all was failed. I think in all cases the files where not to compress for "compress".
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
It seems now that the only place where could this be solved is tar component, so moving from compress ~> tar. Decreasing the Severity tag here also. The bug is unlikely to happen (the -Z option is somehow obsoleted, the entropy of source data must be quite high) and most importantly — archived tarball is completely and successfully created. This bug is just about fixing tar to not fail with exit value 2 (and do not say to user that something failed) when everything is fine. Possibly, we could better document this in manual page and encourage user to use different compression). Pavel
I very appreciate this bug report but it is somehow more principally complicated to fix than I expected before. Per upstream discussion: http://www.mail-archive.com/bug-tar@gnu.org/msg03946.html I am closing this bugreport WONTFIX. If you feel there is possible to do something with this issue, feel free to continue with comments. ----- Because of tl;dr upstream thread, the main reason is that GNU gzip and compress have bad APIs (yes, gzip has the same problem as compress) and if we fixed tar for that upstream, (a) GNU gzip people would be held to not change "broken" API and (b) non-GNU gzip implementation would result in failures by default when used by GNU tar. The reason why I think this is not worth to fix downstream is that it would be quite complicated fix for very unlikely problem (e.g. we would have to incorporate new non-upstream options - as simple program name comparison is not good enough). The result would be uncomfortable divergence against upstream. Pavel