|
|
When using symbolic links in an NFS environment, it is important to understand how pathnames are evaluated. The rule by which evaluations are performed is simple. Symbolic links that a client encounters on the server are interpreted in accordance with the client's view of the file tree.
Users on a server system must keep this rule in mind when they create symbolic links in order to avoid problems. The examples that follow illustrate situations in which failure to consider the client's view of the file tree can lead to problems.
Symbolic links with NFS: example 1
In the example shown in ``Symbolic links with NFS: example 1'', the server advertises its /xenv file system as XENV. If the server creates the symbolic link /xenv/include/sys as an absolute pathname to /xenv/src/uts/sys, evaluation of the link will work as intended as long as a client mounts XENV as /xenv. Another way of saying this is that if the file tree naming conventions are the same on the client and the server, things will work as intended. However, if the client mounts XENV as /mnt/xenv, when the symbolic link /xenv/src/uts/sys is evaluated, the evaluation will be done with respect to the client's view of the file tree and will not cross the mount point back to the server but will remain on the client. Thus the client will not access the file intended. In this situation the server should create the symbolic link as a relative pathname, ../src/uts/sys, so that evaluation will produce the desired results regardless of where the client mounts XENV.
Symbolic links with NFS: example 2
``Symbolic links with NFS: example 2'' shows another potential problem situation in which the server advertises its /xenv file system as XENV. But in this case the server has a symbolic link from /xenv/src/uts/sys/new.h to /foo/xenv/src/uts/sys/new.h. Because the referenced file, /foo/xenv/src/uts/sys/new.h, is outside of the advertised resource, users on the server can access this file but users on the client cannot. In this example, it would make no difference if the symbolic link was a relative rather than an absolute pathname, because the directory /foo on the server is not part of the client's name space. When the system evaluates the symbolic link, it will look for the file on the client and will not follow the link as intended.