Re: [Bug-tar] tar: do not fail hardly when compressor just warns

[Antonio Diaz Diaz]

Pavel Raiskup wrote:
> Hi Antonio, some final comments from my site :).  I don't want to beat
> anyone..  and you are right, the code change would be a little bit larger
> than my initial patch - and I can wait for complains that the change is
> tooo big..

The problem is not (only) that the change is big, it's that the change 
is wrong.


> Yes, ..no!,  warning means that data was successfully compressed, or not?

Tar can't know. What is worse, tar can't even know what compressor it is 
invoking under the name 'gzip', and therefore tar can't know if a given 
non-zero exit status is a warning or an error. The affirmation that 
"exit value 2 is a general warning exit status among compressors" is 
simply false. It seems to be false even among gzip implementations. From 
the 3 gzip implementations I can remember just now, NetBSD gzip[1] 
returns 1 for warnings and 2 for errors, while pigz[2] can return any 
non-zero value to mean error.

[1]http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/usr.bin/gzip/gzip.c?rev=1.105&content-type=text/plain&only_with_tag=MAIN
(see functions maybe_warn and maybe_err).

[2] Pigz documentation (README) says noting about exit status, but the 
source includes code like this:
  exit(err == ENOMEM || err == EAGAIN ? err : EINVAL);


Your proposed modification to tar will change what now is an annoyance 
in rare cases (warnings) to a catastrophic loss of data in those same 
cases if tar is used with a non-GNU gzip. Therefore, the only value tar 
must accept from gzip as success is 0. Just as it does now.


> Do you plan somehow to change the future and fix the compressors APIs?

Julian Seward already began changing the future when he wrote bzip2. I 
only followed his steps when I released the lzip family of compressors, 
all of them with the same correct API of bzip2. It is not my duty to fix 
the APIs of other people's compressors, but I expect conscious users to 
choose the safest APIs.


> Do you really think that users are using 'gzip' *only* through a tar?

It is you the one that seems to think that GNU tar does never use a 
non-GNU gzip. Or that "gzip API" == "GNU gzip API".


> If you make a change in gzip API ~> chaos will come.

I can't see how chaos would develop if GNU gzip stops returning 2 and 
limits itself to returning 0 when the data has been positively 
(de)compressed without error and 1 in any other case.


Best regards,
Antonio.