Bug 759371

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