marty@amc-gw.amc.com (Marty Akerman) (08/23/90)
I'm new to this newsgroup, so I don't know if this has been discussed before or not. We have PC-NFS version 3.0.1 running on a variety of PCs here, and it was recently noticed that they do not seem to see the majority of symlinks in NFS mounted file systems. In fact, the only ones they see are links that point to another file within the same directory. On page 11 of the PC-NFS 3.0.1 Release Notes, this is listed as bug number 1010880 and says "PC-NFS correctly follows symbolic links...." We've had this rev installed for several months, and I thought it was working correctly. But it's been so long that I really can't say for certain. Has anyone seen this behavior with 3.0.1? Do symlinks work as advertised for you? Is there a fix for this problem? Please either post a reply, or send me email. Marty Akerman mary@amc.com System Administrator Applied Microsystems Redmond, Washington
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/23/90)
Quoth marty@amc-gw.amc.com (Marty Akerman) (in <2799@amc-gw.amc.com>): # # #I'm new to this newsgroup, so I don't know if this has been discussed #before or not. # #We have PC-NFS version 3.0.1 running on a variety of PCs here, and it was #recently noticed that they do not seem to see the majority of symlinks in #NFS mounted file systems. In fact, the only ones they see are links that #point to another file within the same directory. # #On page 11 of the PC-NFS 3.0.1 Release Notes, this is listed as bug number #1010880 and says "PC-NFS correctly follows symbolic links...." This probably qualifies for one of the "most frequently asked questions" awards. PC-NFS does follow symlinks correctly. As for ALL NFS implementations, the symlink is interpreted on the client side, and it has to make sense on the client. If not, it won't do what you want. Here are a couple of email fragments on the subject: ============================================================================== >From geoff Tue Aug 23 17:40:35 1988 To: sun!acad!metaware!roadrunner!funkster Subject: Re: Symbolic links are not recognised. Status: RO That's actually not true. PC-NFS will happily follow symbolic links. Try the following on Unix: cd <somedir> mkdir foo1 mkdir foo2 cp <somefile> foo1/bar cd foo2 ln ../foo1/bar baz Now on the PC, mount <somedir>, cd to foo2 and TYPE BAZ. The problem is with absolute symbolic links. If I had instead tried: cd /usr/tmp ln -s /etc/motd foo and then mounted /usr on the PC, it's not going to be able to resolve the link. This is because it's doing it "just like Unix": it sees the symbolic link, replaces the link name with the path, and starts tracing the path. The leading "/" will force it to the root of the drive you mounted /usr on, so it will look at (effectively) /usr/etc/motd. (Gnash teeth.) There is a way to do what you want, but it's not simple. You can use the NET JOIN command (see the manual). Using this, you can arrange for a single remote drive to be the root of a tree containing file systems from one or more servers. Email me if you need further info. ============================================================================== Date: Tue, 14 Feb 89 19:06:48 PST From: ultra!norm@ames.arc.nasa.gov (Norm Finn) Subject: Re: PC-NFS question: symbolic link resolution 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 ============================================================================== In Sun-Spots Digest, v7n180 Jeff Stearns writes >Subject: Re: PC-NFS question: symbolic link resolution >Reference: v7n155 > >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. > [...] >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. [...] Geoff Arnold (garnold@sun.com) Manager, PC-NFS engineering, Sun Microsystems Inc. ========================================================================== -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- To receive a full copy of my .signature, please dial 1-900-GUE-ZORK. Each call will cost you one zorkmid.
sang@daydreamer.East.Sun.COM (Sang Shin - Sun PC Distributed Systems) (09/01/90)
In article <2799@amc-gw.amc.com> marty@amc-gw.amc.com (Marty Akerman) writes: >NFS mounted file systems. In fact, the only ones they see are links that >point to another file within the same directory. If the symbolic link is made relative to the current directory, PC-NFS 3.0.1 does appear to see them.