Standards Update, IEEE 1003.4: Real-time Extensions

[Chip Salzenberg]

[I would like to avoid an NFS flame fest if possible.
 If you respond, please keep it in the context of a 
 UNIX standards discussion, as Chip has mostly
 done here.  Thanks.  --Fletcher ]

Submitted-by: chip at tct.uucp (Chip Salzenberg)

According to nick at bis.com (Nick Bender):
>Any program which assumes that write(2) always works is broken. Period.

True.

>In my view this is not a reason to call NFS a botch.

Also true ... but the possible failure of write() wasn't my reason.

NFS is an interesting and occasionally useful service.  However, it it
does not provide UNIX filesystem semantics.  In particular, given
appropriate permissions, link() and mkdir() on a UNIX filesystem are
guaranteed to succeed exactly once.  On an NFS mount, however, they
may report failure even after having succeeded.

Also, the vaunted "advantage" of NFS, it's statelessness, goes out the
window as soon as you want to lock a file.

Finally, NFS does not permit access to remove special files such as
devices and named pipes.

Yes, Virginia, NFS is a botch.

So what is the relevance of NFS's dain bramage to this newsgroup?
Simply that NFS is not POSIX compliant.  Therefore, using NFS as an
example of how the namespace is supposedly almost useless is nothing
more than a straw man.  If a person wants to knock remote UNIX
filesystems, let him try to knock reasonable ones like RFS and AFS.

No, Dan, this article does not imply that network connections don't
belong in the filesystem.  It means that *if* link() and mkdir() are
defined on a UNIX filesystem, they must succeed exactly once.  Compare
a UNIX system that has mounted a CP/M disk.  The CP/M disk format
precludes the use of link() and mkdir(), yet the UNIX namespace is
quite useful for accessing the files on the disk.
-- 
Chip Salzenberg at Teltronics/TCT     <chip at tct.uucp>, <uunet!pdn!tct!chip>


Volume-Number: Volume 21, Number 191