Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> On Wed, 2005-10-12 at 09:26, Joerg Schilling wrote:
>
> > Note that in case that a filesystem does not implement persistent inode
> > numbers, the content of a renamed directory will _not_ be in the
> > GNU tar incremental.
>
> I'm fairly sure you are mistaken about this.  Any mismatch of the
> filed directory name/device/inode should result in all contents
> being included.  It has been years since I looked at the code but
> I'm fairly sure this concept has not changed.  The only assumption
> is that a matching name/device/inode is not new or renamed and thus
> needs only to observe ctime changes on contained files like a
> normal '--newer DATE' run. On a mismatch or new entry, all content
> is included regardless of timestamps. If no inode numbers matched,
> the incremental run would essentially be the same as a full.

I just verified, you are correct.


> > Then please tell me why GNU tar is used although it's command line syntax
> > does not meet the command line syntax of other tar implementations?
>
> Other tars are irrelevant and have been since the original couldn't
> take device special nodes. GNUtar is used because it is suitable for

Please do not spread this FUD from the net......

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

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

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

 
> full system backups and has had an incremental mode suitable for use
> with amanda for many years.  But, since I didn't use the original tar
> much, I can't think of any command line differences from the tar version
> that existed when GNUtar was first written.  When the GNU extensions
> came first, how could they be compatible with the ones not added to
> non-GNU tar yet?

See above: The FSF did chose to break already existing POSIX compliance and
the GNU tar maintainers still refuse to fix the related lies in the history
part of the GNU tar documentation.

> > Tell me why people complain that star's syntax is supposed to be incompatible
> > to tar while it is only incompatible to GNU tar?
>
> 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.


> > Star's behavior is not changed in an incompatible way (as it happens
> > with GNU tar), so I see no reason for not using recent version. Note that
> > star is the only way to backup ACLs on Linux....
>
> I agree star has it's advantages.  I just wish I could use it by
> replacing my tar with star and have the decade-old wrappers keep on
> working.  How about an /etc/star.conf that can have an option to
> force exact GNU tar syntax if you insist on a less popular default?

Please read the man page.....

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.

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

> > 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....


> > ??? The problem with GNU tar is that dozens of Bugs Reports I did make in 1993
> > have been fixed in 2004. Do you call this reliable maintining an
> > important program like GNU tar?
>
> That's very much irrelevant to me as long as the bugs are fixed before
> they land on my disk.  I don't care if the developer's alpha version is
> broken or not - I've generally come to expect that.

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

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.

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?

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily