Re: LSB Spec 1.0 Criticism
>From: kaih@khms.westfalen.de (Kai Henningsen)
>> On Wed, Jul 04, 2001 at 05:51:49PM +0200, Wichert Akkerman wrote:
>> > Previously Theodore Tso wrote:
>> > > CPIO format files specify file ownerships by numeric ID, not by name.
>> >
>> > As far as I know that is not true.
>>
>> Check out a POSIX.1 specification. Even the extended CPIO format only
>> uses numbers for user and group ownership. Or for an on-line
>> reference, check out:
>>
>> http://www.mkssoftware.com/docs/man4/cpio.4.asp
>>
>> You'll see that even when the ASCII CPIO header is used, the user and
>> group ownership is expressed in a six character wide field in octal
>> ascii digits, zero-padded on the left.
>The next (Austin) revision drops the cpio utility. It keeps the format for
>pax, though, and it still doesn't do non-binary ids.
The cpio format should have never made it into the POSIX spec. It is a very
ugly design which cannot be extended at all without completely beaking
compatibility.
>And the new compromise extended tar format, while it can do just about
>everything, is really a butt-ugly design.
It is a really elegant design which allows infinite future extension without
breaking forward/backwards compatibility.
It gives us many nice things that have been desired for a long time:
- Sub-second time-stamp granularity (needed at least on Solaris & *BSD)
- A POSIX standard way to store _all_ times from struct stat
- A POSIX standard way to store pathnames/linknames of unlimited size
- A way to store uid/gid > 2097151
- A way to store UNOCIDE versions of uname/groupname and path/linkpath
- A way to store files > 8 GB
- ... In future it will give us the possibility to archive ACL's
In a few days, a new 'star' beta will be available with the first free
implementation of the POSIX.1-200x extended USTAR format.
There are two disadvantages of the format:
- it uses at least 1024 bytes of additional data in the archive if
extended headers are actually used.
Fortunately the extra data in the archive is highly compressable.
If you have an archive with many very small files, the archive
grows by 30% but the compressed archive will only grow by ~ 5%.
As an example, the compressed star distribution increases from
378639 to 398249 bytes. This makes it a nice format for distributions.
- The format which uses decimal representation of numbers and additional
decimal length coding for each entry needs more CPU time for creation.
With the current 'star' implementation, this causes star to use up
~ 3x the USER CPU time compared to the non-extended header case.
As this is thill much less than the SYSTEM CPU time this does not
seem to be a real problem.
... of course the user interface of the pax utility _is_ ugly ...
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
Reply to: