dce@mips.COM (David Elliott) (06/13/88)
We have run across a problem with NFS and symlinks that we would like
to solve.
Assume you have a remote path that is actually a symlink.
If that symlink is absolute, the filesystem resolves this path to the
local machine. That is, if the link is to "/etc/passwd", the
resolution is to my /etc/passwd instead of the one on the remote
machine.
If the symlink is relative, the resolution depends on how I have the
filesystems mounted. Assume that the link is in the directory /usr/foo
on the other machine, and that the link is to "../../etc/passwd". Now,
if my system has the remote /usr and remote / mounted in the "typical"
relationship (that is, /usr is mounted on /), and that /usr/foo and
/etc on that machine are set up typically as well, everything works as
expected. If, on the other hand, I have the remote /usr/foo mounted in
my /usr just so I can use it, the link resolves to my local /etc/passwd
again.
What kind of solutions exist for this problem? Do these solutions
take into account the possibility that the target of the symlink may
not be on a mounted filesystem?
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcedce@mips.COM (David Elliott) (06/14/88)
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. > >Assume you have a remote path that is actually a symlink. I've gotten a number of responses, and I think I need to add something. We're trying to solve the problem for our systems as distributed, not just our in-house systems. We can easily go through our internal machines and fix their symlinks, but we can't assume that customers will be using our method of organization. So, as a first shot, I'd like to suggest that there be a modification to symlinks that a special leading symbol mean 'root of the machine on which this file resides'. For the sake of starting some discussion, I'll suggest '...', though I realize that there may be conflicts. So, if I point /usr/ucb/newaliases at '.../usr/lib/sendmail', this would imply "go to the root of the remote machine and then go down to usr/lib/sendmail". Obviously, this has to take into account whether or not the final file is remotely mounted. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
barmar@think.COM (Barry Margolin) (06/16/88)
In article <2378@quacky.mips.COM> dce@quacky.UUCP (David Elliott) writes: >So, as a first shot, I'd like to suggest that there be a modification >to symlinks that a special leading symbol mean 'root of the machine >on which this file resides'. For the sake of starting some discussion, >I'll suggest '...', though I realize that there may be conflicts. What if you don't have the remote machine's root mounted? Also, even if you do have the remote machine's root mounted, there is no way for the local machine to know that, since there is nothing in the NFS protocol that allows a client to find out if a particular directory is the remote machine's root directory. Don't say that if the remote mount is for "machinename:/" it is the root; this only works if the remote machine is a Unix system, but NFS is not supposed to be Unix specific. In particular, we have the following entry in our /etc/fstab: aquinas:> /lispm/aquinas nfs ... This is the entry for a Symbolics Lisp Machine running an NFS server; these machines use ">" where Unix uses "/". Thus, the above represent's Aquinas's root directory, but there's no standard way for the client to determine that. I'm not crazy about the NFS protocol, but I'm not about to propose any changes to it. Given the protocol as it stands, the problems with links are inherent. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
liam@cs.qmc.ac.uk (William Roberts) (06/24/88)
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