jason@mtxinu.com (Jason Venner) (02/15/89)
Does anyone know how pc-nfs resolves symbolic links (or nfs for that matter). The problem I have is that I mount a file system on the pc, and it has some symbolic links in it. If I mount the unix tree from root on a drive, symbolic links work fine (if the would work fine on the nfs server). If I mount a subtree as root, but mount things so that the sym links should be resolved (ie on the PC, all the relevant paths/files are there) the symlinks do not show up in ls listings. Help! Jason
norm@ames.arc.nasa.gov (Norm Finn) (02/28/89)
When you mount a directory on the PC, you use a command like: C:> net use e: \\solar\u2 to mount Solar's directory /u2 on PC drive E. A PC has a root directory on every drive; drives are NOT mounted like in Unix, with additional drives looking like subdirectories on a master directory tree. Solar's directory /u2/fred/sources is known as E:\FRED\SOURCES to the PC. A symbolic reference to /u2/sam/bin causes the PC to look on drive E for \U2\SAM\BIN, which is not present. If you mount Solar's root partition on the PC's E drive, then there is no problem, because E's root partition is the same directory as the Unix root partition. This is not to say that PC-NFS cannot follow links or that you must mount the root partition, however. A symbolic link in /u2/fred/sources to the directory "../../sam/bin" is a perfecly valid link to /u2/sam/bin and perfectly well understood by both PC and by Unix, because both can track down the ".." chain. As long as the string of "../"s doesn't stretch up over the top of the point at which the tree is mounted on the PC (in this case, above /u2 to /), then both PC-NFS and Unix can follow the link. PC-NFS seems to ignore symbolic links it cannot resolve. That's why you don't see them from the PC. Resolvable symbolic links are resolved and the target displayed as if it were a normal file. NOTE: This information has been gained from experience in using PC-NFS, not from reading the source code or even the manuals, so if someone on the net knows better, feel free to correct me. Norm Finn domain: norm@ultra.com Ultra Network Technologies Internet: ultra!norm@ames.arc.nasa.gov 101 Daggett Dr. uucp: ...ames!ultra!norm San Jose, CA 95134 (408) 922-0100
jeff@tc.fluke.com (Jeff Stearns) (03/04/89)
kadmon!jason@mtxinu.com (Jason Venner) writes: >Does anyone know how pc-nfs resolves symbolic links (or nfs for that >matter).... >If I mount a subtree as root, but mount things so that the sym links >should be resolved (ie on the PC, all the relevant paths/files are there) >the symlinks do not show up in ls listings. At mount time: # /etc/mount host:pathname "directory" - Symbolic links in the pathname argument are pursued by the server at mount time. - This behavior is uniform for clients of all architectures because the server is processing the pathname argument. Mounted filesystems: - The pathname resolution rules for NFS files depend on the client architecture. - UNIX clients follow symbolic links in pathnames. (Keep in mind that pathnames in symlinks are followed FROM THE CLIENT'S POINT OF VIEW.) - PC-NFS clients don't know what a symlink is. Period. Symlinks are "invisible" to PC-NFS clients. Thus they can't be followed. -- Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff PS - Calling all users of the Vitalink TransLAN IV Ethernet bridge! Please drop me a line.
news%glimmer%twitch@att.att.com (04/19/89)
[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)!