(was slashes, now NFS devices)

[Larry McVoy]

In article <14367 at ulysses.att.com> ekrell at ulysses.att.com (Eduardo Krell) writes:
>In article <FWP1.91Feb23160240 at Jester.CC.MsState.Edu> fwp1 at CC.MsState.Edu (Frank Peters) writes:
>
>>You ignore (or aren't aware of) two important differences between RFS
>>and NFS that make this impractical.
>
>No, I'm well aware of the difference between RFS and NFS. RFS is a distributed
>Unix filesystem and guarantees Unix semantics on remote files.

Ah, I love it.  NFS bashing week, how silly of me not have marked my calendar.
Much as we know and love Unix file semantics, not all the world runs Unix.
NFS, unlike RFS, is a successful networked file system precisely because
it choose to implement an interface that was supportable by other operating
systems.

>>   The concept of a file
>>   system entry that points to a device by magic major and minor codes
>>   is very OS specific.  While that concept is by no means unique to
>>   UNIX it is far from universal and implemented differently wherever
>>   it is found.
>
>I don't see how this implies that the client should interpret the
>special file. What if the client is a PC running DOS?

I think that you've missed the point.  Special files are merely entry points
into devices.  It is much more likely that the file makes sense to the client
than the server.  It has nothing to do with DOS.

>And to Unix users, NFS is not stateless. What is rpc.lockd used for?

Whew!  Where did this come from?  NFS is stateless.  The locking gunk is
and has been a problematic aspect for some time.  Sorry.  That's one of
the main reasons that the locking is a wart on the side.  It's hard to
get right.
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm at sun.com