J?rg, I don't recall if you were at the 1986 Denver usenix discussions that yielded pax, but the rancor of the tar/cpio discussions up to that point made it clear that a single "tar" or single "cpio" only solution would be impossible -- basically a hung jury
since most of the disagreement was on the formats and since there were even disagreements between some of the existsing apis we realized that a single api would eliminate most of the problems holding up concensus the pax interface was forged at a dinner atop some denver restaurant with thunder storms circling about the whole evening (probably some kind of daemonic omen) that next week I had the initial at&t research pax working for both the proposed standard cpio and tar formats (recall the standard initialily had both) unfortunately at that time it there was no opensource equivalent at at&t and a surprisingly narrow corridor between bell labs research and the commercial at&t unix organization -- I think the only major items to pass that way (after unix itself) were ksh and streams so the first public pax was Mark Colburn's I believe Colburn's implementation missed the boat because I believe pax should be able to crack any popular archiving format in any of its popular forms, including compression the at&t pax does this by defining a plugin api (via dlls/shared libs) and letting those plugins do most of the work and the -x, --format=format option allows the format to be composed with a compression method (and has room for other mthods like encryption) e.g., --format=tar:gzip for tgz, --format=tar:bzip for tbz and also has an extension for base + delta archives -- a very efficient mechanism for patches and version management I'm sure the venn diagram of star + att pax has many interesting properties with benefits for both implementations and the opensource community e.g., I'm sure that star handles some format implementations missed by att pax and vice versa -- that's no problem for att pax because at worse it would mean just another plugin, with no change to the main code (or possibility of interference with the already tested formats implemented by the other plugins) however, at this point the issue of command line api is a dead horse the rest can be discussed on another forum I won't post any more about pax here -- Glenn Fowler -- at&t Research, Florham Park NJ -- On Tue, 24 Mar 2009 20:05:57 +0100 Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: > Jennifer Pioch <piochjennifer at googlemail.com> wrote: > > Why? AST pax is the original pax which supports more file formats than star. > AST pax is not the "original pax". > The early POSIX.1-1988 drafts in 1987 did only include tar. USG (AT&T) did > come > up with the wish to add cpio around 1988. This created the "tar wars" that > have > been fought out around 1990. The winner was a program "pax" from Mark H. > Colburn > that implemented an interfact that nobody liked. > Since then, many pax implementation have been created. AST pax is one of them. > The advantage of star is that star not only implements pax but star is a > archiver library that is easy to configure for new archive formats and new > command line interfaces. > Star implements the "star", "gnutar", "suntar", "cpio" and "pax" CLI. > Star also implements many additions to do incremental backups, to archive any > current and future meta data and star implements a shared memory based FIFO > that > significantly increases performance. > Not to mention that it was star, Solaris added the lseek(f, pos, SEEK_HOLE) > for > to allow star to archive 100% accurate holey files. > Star is developed on SunOS since February 1985 and star is well integrated to > Solaris. Star includes a built in find(1), a configurable diff option, a > configurable error control and many other nice features. > See also http://cdrecord.berlios.de/new/private/star.html > Why do you like to have a different implementaion? > We only wait for the will from Sun to cooperate.....star is ready since many > years. > J?rg
