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
>>
>>
>
