Re: tar: minor POSIX incompliance
>From: Paul Eggert <eggert@twinsun.com>
>> From: Joey Hess <joey@kitenet.net>
>> Date: Mon, 25 Mar 2002 14:57:20 -0500
>>
>> According to the test suite documentation, POSIX 10.1.1-12(A) says
>> that Fields mode, uid, gid, size, mtime, chksum, devmajor and
>> devminor are leading zero-filled octal numbers in ASCII and are
>> terminated by one or more space or null characters.
>OK, I'll change the behavior of GNU "tar" in a future release.
I am not sure what the text from Joey Hess should be related to...
... his mail did not reach this group.
>From looking at the archives created by GNUtar, I see the following deviations:
- Checksum field repeats a bug found in ancient TAR implementaions.
This seems to be a rudiment from early tests done by John Gilmore
in PD tar where he did try to run "cmp" on PD-tar vs. Sun-tar
archives.
This is a minor deviation and easy to fix.
- The devmajor/devminor fields are missing if the file is not
a block/char device - here we see non left zero filled fields.
A minor deviation that is easy to fix.
- The Magic Version field contains spaces instead of "00".
This is just a proof that GNUtar is not POSIX.1-1990 compliant
and should not be changed before GNUtar has been validated to
create POSIX.1 compliant archives.
...
>conformance by running the "tar" command. A POSIX test suite should
>invoke the "pax" command instead.
While this is the correct answer from theory, you should take into account
that "pax" has not been accepted by a major number of people in the community.
AFAIK, LSB intends to be UNIX-98 compliant, so it would make sense to support
cpio/pax/tar in a way compliant to the SUSv2 document.
Let me comment on the current Linux status. We have:
- GNUcpio which is neither POSIX.1-1990 compliant nor does it allow
to archive files >= 2 GB.
For a list of problems look into:
ftp://ftp.fokus.gmd.de/pub/unix/star/README.otherbugs
- GNUtar which is not POSIX compliant too but supports files >= 2 GB.
Problems with archive exchange with POSIX compliant platforms:
- does not handle long filenames in a POSIX compliant way.
This has become better with recent alpha releases, but
gnutar -tvf archive still does not work at all.
Archives containing long filenames and created with gtar
cannot be read by POSIX (only) tar implementations correctly.
- Is for unknown reason unable to list archives created with other
TAR implementations (e.g. Sun's tar on Solaris or star).
For an example look into:
ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/README.gtarfail
- Pax (the version fixed by Thorsten Kukuk) is POSIX.1-1990 compliant
but it is not able to handle files >= 2 GB.
as part of commercial Linux distributions. From a standpoint of what people
might like to see, this could be better. A year 2002 POSIX OS should include at
least one program that creates POSIX compliant tar archives _and_ supports
large files.
People who get and compile software themselves may also use "star" which is
POSIX.1-1990 andd POSIX.1-2001 compliant and supports files >= 2 GB.
So why is star missing from Linux distributions?
>Also, I should mention that GNU tar does not generate POSIX-format
>ustar archives, nor does it claim to. Volunteers to fix this
>deficiency would be welcome, but that's a different topic. It is a
>quality-of-implementation issue, and is not strictly a
>POSIX-conformance issue.
There is "star" which is POSIX compliant. A good idea would be to move
gnutar to /bin/gtar on Linux and put star on /bin/star and /bin/tar.
This way, Linux gets a POSIX compliant TAR and users of gnutar will be granted
to have 100% backward compatibility when calling "gtar".
ftp://ftp.fokus.gmd.de/pub/unix/star/aplha/
If you don't like to do the transition too fast, here is an idea for an
intermediate step:
Put star on /bin/star, install the star man page for "star" and "tar" and move
the GNUtar man page to "gtar".
/*--------------------------------------------------------------------------*/
Another topic:
>From a discussion at CeBIT, I am now aware of the fact that LSB did
"standardise" on the GNUtar options at:
http://www.linuxbase.org/spec/gLSB/gLSB/tar.html
Let me comment on this too:
It seems to be a bad idea to standardize TAR options that are incompatible
with POSIX standards. So let me first introduce a list of incompatible options
found in GNUtar. The complete list is in:
ftp://ftp.fokus.gmd.de/pub/unix/star/aplha/STARvsGNUTAR
/*--------------------------------------------------------------------------*/
Gnu tar options that (in the single char variant) are incompatible:
BsS -F, --info-script=FILE run script at end of each tape (implies -M)
s -L, --tape-length=NUM change tape after writing NUM x 1024 bytes
s -M, --multi-volume create/list/extract multi-volume archive
s -O, --to-stdout extract files to standard output
sS (+) -P, --absolute-names don't strip leading `/'s from file names
s -S, --sparse handle sparse files efficiently
s -T, -I, --files-from=NAME get names to extract or create from file NAME
s -U, --unlink-first remove each file prior to extracting over it
s -V, --label=NAME create archive with volume name NAME
s -d, --diff, --compare find differences between archive and file system
sP -l, --one-file-system stay in local file system when creating archive
sP -o, --old-archive, --portability write a V7 format archive
B Incompatible with BSD tar
s Incompatible with star
S Incompatible with Sun's/SVr4 tar
P Incompatible with POSIX
+) This option is the only option where star deviates from other tar
implementations, but as there is no other nice way to have an option to
specify that the last record should be partial and the star option -/
is easy to remember as well as -P for Partial record is I see no need
to change star.
/*--------------------------------------------------------------------------*/
Please note that all these incompatibilities are "against" other TAR
implementations that are much older than GNUtar. As as example, let me use the
-M (do not cross mount points) option in star which is available since 1985.
It looks inapropriate to me to include single char options from GNUtar that are not
found in other tar implementations into something like LSB.
To avoid LSB systems to break POSIX.1-1990 and SVSv2, I would recommend to
change http://www.linuxbase.org/spec/gLSB/gLSB/tar.html so that the following
single char options will disappear (oder is the order from the web page):
-A This option has low importance and there is no need to have a single
char option for it.
-d (*) Use by star with different semantic, the short option should not
1be in the LSB standard.
-F (*) Used with a different semantic by BSD tar for a long time
the short option should not be in the LSB standard.
-G The short option should not be in the LSB standard.
-g The short option should not be in the LSB standard.
-K The short option should not be in the LSB standard.
-l This option violates the POSIX/SUSv2 semantics, it needs to be removed
from the LSB standard.
-L (*) The short option should not be in the LSB standard.
-M (*) The short option should not be in the LSB standard.
-N The short option should not be in the LSB standard.
-o This option violates the POSIX/SUSv2 semantics, it needs to be removed
from the LSB standard.
-O (*) The short option should not be in the LSB standard.
-P (*) The short option should not be in the LSB standard.
-R The short option should not be in the LSB standard.
-s The short option should not be in the LSB standard.
-S (*) The short option should not be in the LSB standard.
-T (*) The short option should not be in the LSB standard.
-V (*) The short option should not be in the LSB standard.
-W The short option should not be in the LSB standard.
*) Used by one or more other TAR implementations with different semantics
so defining it in LSB creates problems.
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to lsb-test-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
Reply to: