Symbolic links and RFS

[Guy Harris]

>Question: If a remote file is a symbolic link, will that symbolic link
>be interpreted on the remote machine or on the client?

I think it'll be interpreted on the client.

>Either answer seems to break the transparentness of RFS:

Yup.  As the saying goes, Shit Happens.

>If the symbolic link is interpreted on the local machine, the contents
>of a remote file (in this case the file "foo" under resource ALPHA) depends
>on the eyes that see it. This is not transparent. And it is also rather
>useless.

Wrongo.  It is *not* useless.  There are times when I've *wanted* to
have a symbolic link on a server point to different files on different
clients of that server.  Consider, for example, the SunOS 4.0 scheme for
supporting diskless clients.  You have a directory name "/var" in which
things like mail spool areas, printer spool areas, accounting files,
etc. are put; however, many of those areas have "old-fashioned" names
containing "/usr" rather than "/var" - e.g., "/usr/adm".  "/usr" is a
file system that is exported read-only to the diskless clients, and is
shared by the clients; you can't put "/usr/adm", "/usr/spool", etc.
there.  So "/usr/spool" is a symbolic link to "/var/spool", which is a
directory on your local machine.

The problem is ultimately intrinsic to any distributed file system where
you're allowed to mount directories from remote machines on arbitrary
mount points; you don't have a common global file system name space
that's *identical* on all machines, and there are, frankly, reasons why
you may not want to have that (for instance, when at Sun, I mounted the
"/usr/src/man" directory from the main development source repository
machine atop "/usr/man", so that any time anybody checked in a new man
page I'd get it as part of my on-line man pages; other users wouldn't
necessarily want this, since they might be running a stable version of
the OS and would want a stable version of the man pages).