Margot Miller wrote: > 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.
Ok. A hypothetical ARC case proposing star to replace tar would probably need to move this option to the "Obsolete" commitment level. >> >> >> -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. So the questions I have here are: can the older incompatible Sun formats be unarchived by star, and can older Sun tar extract archives with the star POSIX-compliant extension? >> >> >> -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. For an ON-quality integration, I'd prefer to see this option silently ignored. The man page can indicate it is for compatibility only. (A warning would only be required if some user-noticeable behavior changed -- but that's not what I think you're saying -n does -- its an optimization that star can't use, and perhaps, doesn't need or benefit from.) >> >> >> -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. If the docs are wrong, then lets just fix the docs! >> >> >> -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. Weird. Can you provide details about the differences between the docs and the actual implementation? >> >> >> -@ 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 -@ Right, this was the subject of earlier debate. We'd need this "feature" in a /bin/tar replacement. >> >> -z This is a completely undocumented Sun tar >> option that is incompatible to all other >> tar implementations. Undocumented options can probably be excised. -- Garrett >> >> >> >>>> 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 >> >> >