Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: news%glimmer%twitch@att.att.com
Newsgroups: comp.sys.sun
Subject: Re: PC-NFS question:  symbolic link resolution
Keywords: Networks
Message-ID: <8903301107.AA18055@rice.edu>
Date: 19 Apr 89 00:01:01 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 48
Approved: Sun-Spots@rice.edu
Original-Date: 30 Mar 89 08:51:08 GMT
X-Sun-Spots-Digest: Volume 7, Issue 231, message 2 of 9

[Normally I handle issues raised in Sun-spots via email to the author of
the original posting, but I feel this issue needs to be clarified for the
whole group. GMA]

In Sun-Spots Digest, v7n180 Jeff Stearns writes
[...]
>Mounted filesystems:
>
>  - The pathname resolution rules for NFS files depend on the client
>    architecture.

Strictly speaking, yes. However I know of no implementations which would
not expect a symbolic link to be a Unix-style path, with "/" component
separation and the usual interpretations for "." and "..". Anything else
would be theoretically defensible but practically useless....

>  - UNIX clients follow symbolic links in pathnames.  (Keep in mind that
>    pathnames in symlinks are followed FROM THE CLIENT'S POINT OF VIEW.)

Correct. This is one of the biggest sources of confusion over symbolic
links. 

>  - PC-NFS clients don't know what a symlink is.  Period.  Symlinks are
>    "invisible" to PC-NFS clients.  Thus they can't be followed.

But this is incorrect. PC-NFS clients DO know what symbolic links are, and
in most cases will follow them correctly. But as Jason says, pathnames in
symlinks are followed FROM THE CLIENT'S POINT OF VIEW.  Relative links are
simple (e.g. foo -> ../bar), but for absolute links (e.g. foo ->
/usr/tmp/bar), PC-NFS sees the leading "/" and begins path processing from
the root of the mounted drive (D: or G: or whatever). It is possible to
use "net join" to construct a hierarchy which is equivalent to that seen
on the server, but this is a tricky and little-used feature.

There is one bug (well, strictly speaking it was a design decision, but it
turned out to be another of those "theoretically defensible but
practically useless" things) which affects this: the link must be a legal
DOS path, i.e. no upper-case of illegal characters, 8.3 names, etc. This
is due to the way we handle name mapping, and turned out to be the source
of much confusion since (surprise, surprise) people want to use symbolic
links to hide U*xisms from DOS. This behaviour will be fixed in the next
release (no dates yet). (And sorry, there isn't a patch for it.)

Geoff Arnold (garnold@sun.com)
Manager, PC-NFS engineering, Sun Microsystems Inc.

Disclaimer: I speak only for myself. My kids, wife and cat would have me
shot if I claimed to speak for them (especially my 12-year old daughter)!