POSIX bashing (Was Re: Retaining file permissions)

[Chuck Karish]

In article <3419 at unisoft.UUCP> greywolf at unisoft.UUCP (The Grey Wolf) writes:
><21795 at yunexus.YorkU.CA> by oz at yunexus.yorku.ca (Ozan Yigit)
>& In article <see ref> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>& >	      ... one thing I consider broken about POSIX is that there's no
>& >st_blocks field in its stat structure; more generally, there is no standard
>& >way in POSIX to find out how much space a file actually occupies on the disk

This looks like an issue of filesystem implementation that's beyond
the scope of 1003.1.

>Incompleteness, in many ways, is congruent to brokenness.  "Well, in the
>future, we want it to deal with that problem, but for now it doesn't ad-
>dress it." is synonymous with "Well, it's broken."

Yes, and my hammer is broken because it's not a screwdriver.

There are, in fact, other groups working on different standards that
bear more directly on this problem than did 1003.1.  The 1003.7 (system
management) committee may have something to add.

>I think that POSIX is an attempt at an implementation of a bare-bones OS.
>There are too many things there which are simply done wrong.  I agree with
>Jon on this one.

POSIX.1 isn't an OS at all; it's a specification for a programming
interface.  It's always going to be necessary to write system-specific
extensions, no matter how "complete" the standards are.

For an illustration of the difference between a specification and an
OS, consider the variety of operating systems that could be written to
conform to the 4.3BSD manuals.  It's the exception rather than the rule
for a manual page to completely specify error returns.  Luckily for us,
the market for BSD systems has been based on the (relatively sane)
performance of implementations rather than on the completeness of the
specification.  The SVID is similarly incomplete.

	Chuck Karish		karish at mindcraft.com
	Mindcraft, Inc.		(415) 323-9000