Re: Perfomance problem backupscript (more details and tests)

On Thu, 2005-10-13 at 07:20, Joerg Schilling wrote:

> Star did support devices sine 1985 (using proprietray enhancements)
> and PD/SUG tar did start to support POSIX.1-1988 in 1987.

Posix 1.x was less than useful.  It specified nothing that really
existed, and if it had existed, would not have been usable.  Probably
the only thing that ever really followed that spec was the subsystem
in Windows NT that got them some sales but no one ever used it.

> Other tar's did start to support POSIX.1-1988 around 1990 (this includes
> Solaris - the most posular UNIX).

UNIX?  Is that still around?  I gave up on Solaris when it would have
cost more for a software update from the horribly buggy 2.4 to something
that worked than it did to replace the hardware with faster pentium
boxes running a free version of Linux.  I've never had a reason to
reconsider that decision.


> GNU tar was created 1989 from PD/SUG-tar by breaking POSIX.1-1988 compliance 
> of the original source :-(

And thus it became usable.

> > It will not work with amanda - or anything else that has been written
> > to use GNUtar's features.
> 
> This is a problem of the obviously missing maintenance for Amanda.
> As Amanda claims to support ufsdump/ufsrestore, it should take about
> 2 hours (for a person who knows the Amanda source) to add a different
> CLI string for a _very_ similar interface.

Agreed - it could now replace dump easily on the backup side. It's not
a drop-in replacement for tar since it will not work in all the same
situations.  So you'd need a backup side driver like dump's and a
restore-side more like tar - not sure where indexing falls.

> If you create a link to star that starts with a 'g', the CLI is 99% compatible.
> Of course star does neither implement the GNU tar incremental CLI
> nor the strange bugs of the GNU getopt() function.

The 1% that is impossible is the problem.  If it were just syntax we
could use a shell wrapper.  And neither the GNU or stock getop() works
with old tar syntax.  That's the one thing that should have been broken
on purpose by the first usable version and everyone would have forgotten
it ever existed by now.

> BTW: /etc/star.conf would not be compliant to UNIX rules. Star of course
> reads /etc/default/star and if this is missing or of star is called "tar",
> /etc/default/tar

There's that UNIX word again.  I expect my software to be fixed to use
the conventions of my distribution, regardless of the originality of
the developer.  Packagers for other distributions should do the same.
I'd prefer that anything built from a developer's tarball land
entirely under /usr/local, but I don't expect any agreement about that.

> > > Why then do you use internal developer releases of GNU tar?
> >
> > I don't.  I use the tested version included and updated for
> > the OS distribution - as I do for all the other programs
> > I run.  I don't like surprises.
> 
> You do! otherwise you would observe the bugs I told you....

I can observe one bug - the directory replaced by a file not
being removed in the incremental restore.

> So you don't use GNU tar frequently and don't see the bugs?

Apparently I don't do anything that triggers them.

> The first GNU tar bug was a bug I reported in 1993 for GNU tar reading star
> archives (error message: skipping to next header). This bug has not been
> fixed until the end of last year. The GNU tar maintainers told me that this
> was a star bug although it obviously was a GNU tar bug. Last year people
> did report the same problem to be present with GNU tar archives too.

I have no problem with GNUtar using a unique format.  I don't foresee
any situation where using GNUtar to extract/restore would present a
problem, given source availability.   I would be interested in any
repeatable way to produce GNUtar archives that GNUtar won't read
itself.

> Now tell me please: do you trust in a tar implementation that is maintained
> in way that ignores bug repports for showstopper bugs for more than 10 years?

Compatibility with ever-changing standards committee decisions isn't a
big priority to me, especially for something that pre-dates them.  Some
of the other bug reports and the times to fix are troubling, but I don't
see that continuing with extremely popular Linux distributions doing
their own maintenance on packages.  However, you are missing the point
here.  I don't want to defend GNUtar, I want to replace it.  I just
can't until there is another equally filesystem-boundary-agnostic
replacement.  Star isn't that now, and won't be unless you add a
similar incremental mechanism.  Even then it would be difficult for
me to switch without compatibility with my old GNUtar tapes in the
amanda rotation.  I don't want to lose the ability to tell amanada I
want a file from some earlier date and have it tell me which tape
to insert.

-- 
  Les Mikesell
    [email protected]