Darren J Moffat <[EMAIL PROTECTED]> wrote:
> James Carlson wrote:
> > Joerg Schilling writes:
> >> James Carlson <[EMAIL PROTECTED]> wrote:
> >>> Actually, the extensions are *far* older than that. They're
> >>> compatible with the extensions present in Trusted Solaris 8 and
> >>> previous releases. My time machine is on the fritz right now, but
> >>> otherwise I'd volunteer to go back and help change that release.
> >> POSIX.1-2001 predates TS-8
> >
> > We _shipped_ TS8 in 2000, and it was clearly designed well before
> > that. POSIX.1-2001 is that old?
>
> Trusted Solaris 8 is heavily based on work done for Trusted Solaris
> 2.5.1 (which was actually released the same day as 2.6) and that heavily
> based on Trusted Solaris 1.x (SunOS 4.1.3*) and SunOS CMW and SunOS MLS
> before that. There is a history going back at least 15 years hear.
If the tar extension is really this old, then I would even more expect to
find a documentation for the archive format it uses.
If something has been in a different product, this does not give the
permission to add it to OpenSolaris as it is still undocumented.
There are a lot of badly implemented programs in operating systems from the
1960s. Does this give you the permission to add them to OpenSolaris without
a discussion? I believe that NO and you need to meet the requirements of
today in order to add something into OpenSolaris.
The _way_ several extensions have been added into Sun tar is the problem.
The POSIX.1-1988 tar definition does not give you a method to tag a vendor
name to vendor specific extensions. POSIX.1-1988 based tar extensions are
based on a single character only! If you see the letter 'Y', could you tell
which vendor did use it for what purpose? As there are only 25 letters
available for POSIX.1-1988 based tar extensions, so there is a high potential
for a name space conflict.
Star as well as GNU tar did also add POSIX.1-1988 in former times. This is
however not a real problem because:
- GNU tar clearly claims _not_ to be a POSIX.1-1988 compliant TAR.
This is done by using "ustar " instead of the official POSIX.1-1988
TAR magic: "ustar".
BTW: The GNU tar maintainers did recently add new features and
did try to remove the GNU TAT "ustar " fingerprint. As a result,
star did not like to unpack these archives. The GNU TAR maintainers
did learn from this problem. They now (with the latest GNU TAR version)
either create _old_ GNU TAR archives tagged with "ustar ", or they
completely switch to POSIX.1-2001 based extensions.
- Star adds other "fingerprints" into the tar header that allow to
detect whether a tar archive has been written by star or a compatible
program.
This is not true for Sun tar because:
- Sun tar (with a few exceptions that usually do not happen at the
beginning of the archive) does not add anything to the TAR header
that would allow to identify an archive as a "sun tar" archive.
Star is the tar implementation that deals with most different archive
flavors. When star is starting to read an archive, it looks for ways to
identify the archive type to be one from this list:
v7tar Old UNIX V7 tar format
tar Old BSD tar format
star Old star format from 1985
gnutar GNU tar format 1989 (violates POSIX)
ustar Standard POSIX.1-1988 tar format
xstar Extended standard tar (star 1994)
xustar 'xstar' format without tar signature
exustar 'xustar' format - always x-header
pax Extended POSIX.1-2001 standard tar
suntar Sun's extended pre-POSIX.1-2001
bin cpio UNIX V7 binary format
cpio cpio POSIX.1-1988 format
odc cpio POSIX.1-1988 with SYSv compat
asc SYSvr4 cpio ascii expanded device #
crc 'asc' format + CRC
Star is usually not able to explicitly detect "suntar" in "read" mode
and asumes "ustar" in such a case. If it then finds "extensions" based
on POSIX.1-1988, it prints something like this:
star -tv < testscripts/ustar-bad-filetypes.tar
star: Blocksize = 7 records.
0 -rw-r--r-- jes/glone Jun 15 16:41 2002 file
star: WARNING: Archive contains unknown typeflag 'y' (0x79) at 1.
0 -rw-r--r-- jes/glone Jun 15 16:41 2002 bad1
star: WARNING: Archive contains unknown typeflag '8' (0x38) at 2.
0 -rw-r--r-- jes/glone Jun 15 16:41 2002 bad2
star: WARNING: Archive contains unknown typeflag ':' (0x3A) at 3.
0 -rw-r--r-- jes/glone Jun 15 16:41 2002 bad3
star: WARNING: Archive contains unknown typeflag 'L' (0x4C) at 4.
0 -rw-r--r-- jes/glone Jun 15 16:41 2002 bad4
star: 1 blocks + 0 bytes (total of 3584 bytes = 3.50k).
Conclusion:
.... Sun tar only works because it incorrectly assumes that _every_
tar like archive it sees is a "suntar" archive. This is the reason
why it is an extremely bad idea to continue adding POSIX.1-1988
based extensions _today_.
The current problem with suntar will only be solved if people inside
Sun understand why suntar creates problems that exist because there
is more than just Solaris and suntar in the world. The only known solution
for the the problems of today is to use methods of today. In case of TAR
this is using POSIX.1-2001 extensions for everyting that is added past
December 2001. Star did start to base _all_ new features on POSIX.1-2001
extensions in August 2001. Will suntar get there eventually?
In the past, we did have several discussions about non-stable interfaces
in Linux that are a result of badly planned interfaces that cannot stand
more than a year. If suntar is conitinuing to add extensions based on
deprecated POSIX.1-1988 features, the same will happen for suntar.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
