Re: [Cdrecord-support] cdrtools-2.01.01a27 ready
Bill Davidsen <davidsen@tmr.com> wrote:
> > If you do not use GNU tar frequent enough, or you may do too simple things.
> >
> >
> Download tar packaged software and unpack it. Very simple thing, but the
> thing which the original poster couldn't do with an star archive.
You stil spread FUD:
The original poster did use a buggy tar implementation.
There was definitely no problem in star.
> > The repeated problems are:
> >
> > 1) GNU tar sometimes writes
> > "... skipping to next header" because it incorrectly asumes
> > that the archive has broken headers.
> >
> > 2) Restoring incremental backups does not work. It seems that
> > this has never ever tested in a systematic way as my tests
> > for star did fail immediately.
> >
>
> I'm sorry that star failed, if that comes from adding changes on the end
> of an archive (append) I can believe it hasn't been heavily tested, most
> people put each incremental backup in a separate file to allow restoring
> to any given level. Note: I'm not saying that's better, just that in my
> experience people don't append incremental data to archives.
What kind of FUD should this be?
star does not fail. star has been heavily tested with inremental backups
and restores.
I was not speaking about appending data to an archive....
GNU tar claims to support incremental backups since 1992, but a very simple
incremental backup and restore test with GNU tar fails completely.
If you do not understand why GNU tar fails, try reading the GNU tar mailing
list. The problem is that the GNU tar archive format does not archive a
sufficient amount of meta data..... GNU tar fails completely in case that a
directory is renamed and a new directory of the same name is created between
two incrementals.
> > 3) ~ 5% of the multi-volume continuation archives are not accepted
> > as valid continuation.
> >
> >
> > With the latest GNU tar version you are able to create standard compliant
> > archives but this is still not done by default.
> For portability that's probably a good decision, since GNU tar "old
> format" seems to unpack with GNU tar, star, Solaris tar, and even the
> old Sys-III, SysV, and SysVR4 tar implementations.
This is definitely wrong!
I cannot understand why you repeat this lie... I did explain more than
once where the problem is. GNU tar uses a nonstandard method to archive
long pathnames. This makes tar, Solaris tar, old Sys-III, SysV, and SysVR4 tar
implementations fail to unpack such GNU tar archives.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: