Thanks Joerg for providing the below star/tar differences. Richard,
Do you need anymore info on these differences? And is it a requirement to have a section in the star man page that summarizes the below differences? Thanks Margot Joerg Schilling wrote: > Rick Matthews <Richard.Matthews at Sun.COM> wrote: > > >>> If called as "tar", star supports the functionality of Sun's tar with a few >>> exceptions. Once, star is in OpenSolaris, I hope this is no longer a rabbit >>> and hedgehog play. >>> >>> >> Are there other exceptions other than those addressed below? So, for the >> purposes of documentation >> I'd like to see the exceptions noted. >> > > -E use extended headers; this option > exists in star, but star warns about the > non-POSIX compliant archive format used > by Sun tar with -E. > > > -k yy archive/volume size - uses this instead > of whatever size the media actually is > > The problem with this Sun tar option is that > it uses undocumented enhancements to the tar > archive format that are in violation with > the POSIX tar archive format. Star implememts > the -k option using a POSIX compliant extension > of the archive format. > > > -n not reading from tape, so can use random seeks > > The problem with this Sun tar option is that > it is easy to implement in a simple tar > implementaion but hard to do in a buffered tar > like star. Star ignores this option and warns > about this fact. > > > -q stop after extracting first instance of > requested file > > The problem with this Sun tar option is that > it is documented but unimplemented. As it is > unclear whether this option should allow more > that one file argument is it not possible to > implement it from the available description. > > > -X yy exclude files named in the file yy > > Not yet implemented in star. > > > -I yy include files named in the file yy. This option > is not documented as it is implemented in Sun tar. > > Not yet implemented in star. > > > -@ included Sun extended attributes in the archive > > Not implemented in star as Sun tar uses deprecated > POSIX.1-1988 extensions. > > -T Trusted extensions. This option is related to -@ > > -z This is a completely undocumented Sun tar > option that is incompatible to all other > tar implementations. > > > >>> There is currently no support for Sun's ACL/extended-attribute archive >>> format >>> that is based on outdated technology. Star however supports a _portable_ >>> ACL >>> archive format that is based on recent POSIX technology for vendor specific >>> extensions. >>> >>> >> I can understand reasons for not writing Solaris format archives, but >> what prevents star or the OpenSolaris >> star project from reading Solaris format archives? Lack of interest may >> be a satisfactory answer, but there >> are those who already have tar-like archives from Solaris. >> > > One problem is that the Sun format is not fully documented and unnessecarily > complex. > > >> From what you've indicated, star supports an archive format WRT ACLs >> that readable and usable by >> tar implementations on other OSs (other than a star implementation). Is >> that correct? >> > > It allows to move ACLs between different platforms. > > > >> Joerg, >> I and others are interested in discussing archive format (tar-like) >> for various applications within Solaris >> > > I would like to discuss a portable format for extended attribute files. > It must be based on POSIX.1-2001 extensions where possible and it should > allow to move attribute content to Linux and FreeBSD if possible. > > All archive format extensions and all other extensions (such as the plug-in > proposal from Glenn Fowler need to be defined in a way that allows to be used > in a buffered tar implementation like star that runs in two processes and > imposes the following constraints: > > - one process handles the archive content but not the archive I/O > (reading/writing of the archive). > > - another process handles the archive I/O but does not know anything > about > the archive format. This affects e.g. the way multi-volume may be > implemented. Star cannot implement the problematic "in-band" method > for multi-volume from GNUtar but uses a reliable "out-of-band" method > instead. > > - lseek(2) on the archive is extremely hard to implement. It is currently > unimplemented. If someone makes a proposal that requires to seek the > archive, we first need to implement and test/verify the implementation > before such a proposal is applicable. > > For obvious reasons, extended attribute information cannot fully live inside > the > hidden POSIX.1-2001 metadata but star may add speficic tags inside the hidden > metadata. > > >> and OpenSolaris. Portability of format is a big deal. Is there a >> OpenSolaris or other discussion >> forum in which these are being discussed? >> > > star-developers at lists.berlios.de looks like a good address for general > discussions, star-discuss at opensolaris.org is for OpenSolaris specific > discussions. > > J?rg > >
