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

Re: [Cdrecord-support] cdrtools-2.01.01a27 ready



Note that this are mailing lists for CD/DVD writing and not lists
for ignoring GNU tar problems. You are off topic.

Bill Davidsen <davidsen@tmr.com> wrote:

> Just fact, O.P. couldn't unpack, I had some people who got stuff from me 
> and couldn't unpack.
> > star creates archives that can be extracted by any halfway bug-free tar 
> > implementaion.
>
> Unfortunately the world is full of tar implementations which don't live 
> up to your standards.

Do you again like to verify that you are ignoring facts?

This is a general official standard.

BTW: 99% of all unpacking problems are caused by GNU tar


> >
> >                           Star is the best solution since 25 years.
>
> Since that's opinion, I won't comment. I said it worked well for backups 
> to be read by star, but I would not recommend it for creating 
> distribution tar files.

Wonderfull to see that you agree.

> > You are trying to make star responsible for problems from broken tar 
> > implementations. Check the "error message" from the original mail and
> > you see that this poor "tar" implementaion must have a heavy bug.
> >   
>
> It may be buggy as an outhouse rat, but it's the tool he has.

Nobody is forced to use software that does not work correctly.

> > Look at GNU tar - I need to _strongly_ recommend using GNU tar for 
> > creating software distributions.
> >   
>
> I'm glad you agree that GNU tar is the one to use in that case.

This was a typo, I strongly recommend NOT to use GNU tar.

Most of the tar unpacking problems in the world are caused directly
or indirectly by GNU tar and the ignorance of it's maintainers to
official open standards

> > -	GNU tar often has problems to unpack it's own archives.
> > 	People need to use star in these cases. If you read the GNU tar
> > 	mailing list, you know what I am talking of....
> >   
>
> My use dates back to the early Linux days, and I have not had such a 
> problem. I'm not saying it doesn't exist, just that I have NEVER 
> personally had a failure of an uncorrupted gnu tar output.

If you do not use GNU tar frequent enough, or you may do too simple things.


> > -	Mysql uses GNU tar to create their distribution and publish
> > 	archives that are so extremely broken, that only some GNU tar
> > 	version can unpack them.
> >   
>
> Having unpacked on RH8, 9, and FC1,  FC3. FC4 and FC6, I repeat that 
> it's not a common problem even if you can identify some broken tar which 
> doesn't unpack. You don't want star blamed for broken unpackers, yet you 
> seem to be blaming GNU tar for the same thing. I assume "only some GNU 
> tar versions" means the ones which some distribution didn't screw up.

This sounds as funny as a person from GB saying: "We in GB of course
drive on the _right_ side of the street".

I am careful with my statements and it may be that some of the bugs are 
fixed in unpublished versions of GNU tar.

I reported these bugs to the GNU tar maintaners first in 1993. I have been 
ignored. Aprox. 2 years ago, many other people started to report the same
problems. Since then this repeats every few months:

-	The maintainers claim that the problems have been fixed.

-	A few months later other people report the same problems
	with the current version of GNU tar.

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.

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.

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: