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

[Pavel Raiskup]

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..  Simply, it makes sense to work on this only if the upstream is
really interested — and in that case, I would be glad to continue.

> > Exit value 2 is a general warning exit status among compressors
>
> Then those compressors have a serious problem with their APIs that
> should be fixed, or at least carefully documented. Callers like tar do
> not mind if there were warnings or not, only if the data was succesfully
> compressed or not.

Yes, ..no!,  warning means that data was successfully compressed, or not?
Saying that the API has a serious problems is the only think you can do
with (and it can be also considered rather like a matter of taste).  Do
you plan somehow to change the future and fix the compressors APIs?

> >>if important programs like GNU tar begin accepting an exit status of '2'
> >>as success for those compressors, it will prevent them from switching to
> >>the correct and sane API
> >
> > This is not so truth, nobody prevents anyone from switching
>
> Suppose that gzip-1.6 begins returning '2' to mean fatal error, just as
> most compressors are already doing (see below). This would work fine
> with the current tar. But if '-z' is modified to accept '2' as success,
> then the new tar with gzip-1.6 would produce truncated archives without
> a warning. This is far worse than giving an spurious error. Therefore,
> if tar is modified, gzip won't.

That will be the time when GNU tar settings must be switched for gzip like
  s/--compress-program/--filter-program/
which will be basically one-liner.  Where do you see the problem?  This is
also usual work of distro maintainer - configure its utility to cooperate
correctly with other utilities.  Thats also why I'm in this discussion
(because the cooperation of utilities is not 100% OK atm).

> > This patch is intended just to make tar work *now* .. don't wait forever.
>
> Passing -f to compress and considering all warnings from gzip as errors
> is the simplest and safest way of making tar work now without
> compromising the future.

Nope, as far as you can not guarantee that it does not silence other
errors.  And no - we are compromising present NOW! ;-) and if we deal here
with your way, we will probably forever.  But it is just my opion.

> > And even if some standard compressor change its API (I see this as an
> > highly unlikely), it is very easily configurable on target distribution
> > tar (distro maintainers can know, which API its distributed compressor
> > uses) - not possible now, thats why I am trying to solve this.
>
> If tar is modified and later some compressor changes its API, user's
> scripts will break and chaos will develop as soon as a partial update is
> made.

This is exactly the reason why is see the API change as unlikely.  Do you
really think that users are using 'gzip' *only* through a tar?  If you
make a change in gzip API ~> chaos will come.

Pavel