Path: utzoo!attcan!uunet!mcvax!ukc!eagle!icdoc!qmc-cs!liam From: liam@cs.qmc.ac.uk (William Roberts) Newsgroups: comp.unix.wizards Subject: Re: Symlinks vs. NFS Message-ID: <514@sequent.cs.qmc.ac.uk> Date: 24 Jun 88 10:25:40 GMT References: <2372@quacky.mips.COM> Reply-To: liam@cs.qmc.ac.uk (William Roberts) Organization: Computer Science Dept, Queen Mary College, University of London, UK. Lines: 63 Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <2372@quacky.mips.COM> dce@mips.COM (David Elliott) writes: >We have run across a problem with NFS and symlinks that we would like >to solve. What you are asking for is "interpret the symlink in the NFS server and then return the file handle", as opposed to the current behaviour which is "return the symlink information and interpret it in the NFS client". This has some merits, particularily when the NFS server understands symlinks but the client doesn't. However it would need to be an additional file type: this doesn't stop YOU implementing it in YOUR NFS SERVER and providing the interface to NFS clients that the NFS protocol allows (rather like the distinction between stat and lstat in fact :-)). In our network, the major ways that we cope with symbolic links are: 1) Use symlinks to go from local filestore to remote filestore, e.g. to "stick on" chunks of /usr when the client doesn't have enough disk (I know we could mount this stuff, but it is sometimes done for individual binaries). Naming is then a purely local problem. 2) Use symlinks with relative paths when connecting related filestores that are likely to be mounted as a group. To be specific, our user filestores on the main machine are called /users/staff and /users/staff2 (too much for one disk), but all staff login names are known in both, e.g. /users/staff/liam - home directory /users/staff2/liam -> ../../staff/liam On other machines, the filestores are mounted as X/staff and X/staff2 for some convenient X (e.g. /sequent, /users or even /nfs/sequent), but the discipline of mounting them as a group means that the relative symlinks still work. Two related things: A) Why do Sun persist in thinking that it is a bug for symlinks to be followed when identifying the directory that is being mounted? Example: On "server": /usr/link -> /usr/games (a symlink) a) mount server:/usr/link /mnt b) mount server:/usr/games /mnt The name "/usr/link" is interpreted on server and resolved to be /users/games, so command a) is actually the same as command b). I have found this useful (on occasion), though I will admit it to be very confusing! B) Does anyone have a table showing which utilities follow symlinks and which don't? I am thinking mostly of adminstrative things like tar, du, cp, dump and so on. -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250