Two kinds of links are covered in the NFS protocol: hard links and symbolic links. Hard links are supported via the NFS LINK operation, and symbolic links are supported via the NFS SYMLINK and READLINK operations.

In BFS there are two basic types of links, hard links and soft links. The symbolic link is a type of soft link; it is a pointer to another file system object, either in the same or a different BFS file space. Another type of BFS soft link is the external link. In addition to symbolic links, NFS clients communicating with a VM NFS Server can reference a type of external link known as a mount external link (MEL). A MEL is similar to a symbolic link; it is a pointer to another directory in the same or a different BFS file space, including the root of a different BFS file space. But unlike a symbolic link, when a MEL is encountered as a pathname component during BFS pathname lookup, a mount is simulated at that point.

The VM NFS Server permits operations on symbolic links and MELs only for BFS. As per the NFS protocol, the contents of these links are not interpreted by the VM NFS Server, but are merely stored. In NFS, pathnames are always parsed on the NFS client, and NFS looks up one component of a pathname at a time. The NFS client interprets the contents of symbolic links and MELs when they are encountered as pathname components.

Thus there can be complications when NFS clients attempt to reference these soft links, depending on what system they were created on, and from what perspective. Symbolic links and MELs can have different interpretations on different NFS client systems, including the way the pathname ".." is handled. In UNIX*-type implementations, ".." is interpreted to mean the parent of a given directory; this use of ".." would be a problem for non-UNIX* implementations. And both types of implementation could have a problem handling the use of ".." in a fully-qualified BFS pathname, which takes the form "/../VMBFS:filepool:filespace/pathname".

Here are some examples involving NFS READDIR operations. The AIX NFS client "ls -l" command displays the names of symbolic links and MELs, and also displays their contents, regardless of whether or not those contents are meaningful to AIX. This is not the case in OS/2. The OS/2 NFS client "DIR" command tries to follow symbolic links and MELs; when it cannot follow the link due to a syntactical misunderstanding, it does not display that directory entry. When a BFS directory is mounted and the OS/2 client encounters the ".." in a fully-qualified BFS pathname, for example, it tries to go to the parent in typical UNIX* fashion, instead of recognizing the BFS syntax.

A good rule of thumb, then, when dealing with BFS symbolic links and MELs from the perspective of an NFS client, might be to create the contents of those links relative to either the expected current NFS client directory, or to the root directory of that file system, and to be aware of which it is that is being done. A slash ("/") at the beginning of a link pathname can imply that the path is relative to the root, and the absence of said slash can imply that the path is relative to the current directory. Thus, care should be taken with the use of "/" at the beginning of a soft link, and fully-qualified BFS pathnames should not be used.

Return to the main z/VM TCP/IP NFS Server Support page.

*UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group.