Joerg Schilling wrote:
The "problem" is that star creates archives which use features not supported in various versions of tar. Not just GNU tar, there are tar versions still in use which predate the standard you chose to implement.Bill Davidsen <davidsen@tmr.com> wrote:Download tar packaged software and unpack it. Very simple thing, but the thing which the original poster couldn't do with an star archive.If you do not use GNU tar frequent enough, or you may do too simple things.You stil spread FUD: The original poster did use a buggy tar implementation. There was definitely no problem in star.
You just said "my tests for star did fail immediately," then you say it didn't fail. Which is it?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.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.What kind of FUD should this be?star does not fail. star has been heavily tested with inremental backups and restores.
I don't think that long filenames are the problem, I think that star does attributes, or acls, or something that the old versions just don't handle. Most software is less than six levels deep and has no single level with a filename not unique in 32 characters. I'm sure you can find a case where that's not true, but when I want to give software away, I make it easy to unpack, and I think others do as well.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 adirectory is renamed and a new directory of the same name is created between two incrementals.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.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 compliantarchives but this is still not done by default.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 archivelong pathnames. This makes tar, Solaris tar, old Sys-III, SysV, and SysVR4 tar implementations fail to unpack such GNU tar archives.
-- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979