[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Antonio Diaz Diaz
Subject: Re: [Bug-tar] tar: do not fail hardly when compressor just warns
Date: Thu, 02 May 2013 21:17:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

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.

(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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]