Hello, the easiest way how to reproduce this issue (in case you have a little bit of luck) issue is: $ dd if=/dev/urandom of=testfile bs=1K count=1024 $ tar -cZf test.tar.Z testfile -rw-rw-r-- praiskup/praiskup 1048576 2013-02-22 16:49 testfile /home/praiskup/projects/tar/src/tar: Child returned status 2 /home/praiskup/projects/tar/src/tar: Error is not recoverable: exiting now $ echo $? 2 This is not _so_ big deal because tarball is successfully created anyway. Just the error return value is confusing for scripts / users. As in is mentioned in $Summary, compress is unable to give to tar sufficient compress ratio -> resulting "compressed" output is bigger then original data. For that reason compress returns the exit value 2 (see man ncompress). Because tar expects 0 return value from its child if the compression went OK, it is confused by the value 2 and fails with confusing error message. Expected behaviour: Do not fail in such cases (possibly warn user by appropriate message). Pavel
Created attachment 701256 [details] Warn only when this issue occurs. Attaching possible solution for this issue.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
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