Xref: utzoo comp.unix.questions:6598 comp.unix.wizards:7824 comp.arch:4367
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <1054@mcgill-vision.UUCP>
Date: 16 Apr 88 07:02:24 GMT
References: <326@ivory.SanDiego.NCR.COM> <275@ksr.UUCP> <7556@brl-smoke.ARPA> <18745@think.UUCP>
Organization: McGill University, Montreal
Lines: 31

In article <18745@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> In article <676@leah.Albany.Edu> rmb384@leah.Albany.Edu (Robert Bownes) writes:
>> NFS was designed to be OS independant.
> While NFS is an admirable protocol, it falls a bit short in totally
> reaching those goals.  For example, for most things NFS doesn't
> require the client machine to parse the server's pathnames, so
> instead the client traverses the client's hierarchy.  However, the
> operation that reads a symbolic link returns a pathname string in the
> server's format.

Not necessarily; it depends on who created the link.  If it was created
by the client with the create-a-symlink NFS operation, the string the
client finds when it reads the link should be identical to the string
it stored there when it created it.

When the client and server have different notions of pathnames,
symlinks can't work on both at once (unless the server tries to be
clever and mungs the path for the client, which defeats the goal of OS
independence).

(Of course, there is another point that should be (has been?) raised:
sometimes you don't want an OS-independent protocol.  Such as when
speaking between two UNIX systems, when you presumably want full UNIX
semantics, which NFS just can't support.  NFS is great if you want
Macintosh, VMS, UNIX, MS-DOS, Lisp Machine, Multics, etc all sharing
files.  But when you have just UNIX machines, it isn't the greatest.)

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu