Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!cjc
From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav])
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic links and RFS
Summary: symlinks, RFS, NFS
Message-ID: <11555@ulysses.homer.nj.att.com>
Date: 19 May 89 02:31:56 GMT
References: <563@Aragorn.dde.uucp>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 54

In article <563@Aragorn.dde.uucp>, ct@dde.uucp (Claus Tondering) writes:
| System V Release 4.0 will support both symbolic links and RFS.
| 
| Question: If a remote file is a symbolic link, will that symbolic link
| be interpreted on the remote machine or on the client?
| 
| <example deleted> 
> Either answer seems to break the transparentness of RFS:
| 
| If the symbolic link is interpreted on the remote machine, I cannot
| create a remote file as a symbolic link to one of my local files. This
| is not transparent.
| 
| 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.

Disclaimer: I have no idea whow the people in Summit actually
plan to do this, these are just my opinions...

I assume that things will follow the way they already work
in NFS, which is that the symlink is interpreted on the local machine.
Essentially, the way symlinks work is that when you do an open() of a
symlink, the name of the file you're trying to open is remapped to the
name the link points to before the actual open is performed (obviously
this is simplified).  Using this scenario, the mapping would have to
take place with regards to the local machine.

Acutally this gives some very nice results if you know how to use it.
For instance, around here we mount /usr on our Suns from a common
server, but /usr/spool is a symlink back to a location on the
workstation's private disk.  The same goes for /usr/tmp and a few
others.  If the link was interpreted remotely, we'd have to mount all
the directories we wanted under /usr instead of /usr itself in order
to allow the local workstations their own space for UUCP, mail, etc.

If you want the symlinks to be interpreted closer to the way they
would be on the remote machine, use relative paths.  For instance,
ALPHA may not be mounted as /alpha on the remote machine, but as
/foo/alpha, but if a symlink /alpha/beta/foo points to ../bar
it will point to the file /alpha/bar on the server machine, and to
/foo/alpha/bar on the client machine, but they'll still be the same
file.

Also, if the names were mapped remotely, it leaves the possibility
that the symlink points to a file is not on a remotely mounted file
system, or to a file system which is not allowed to be remotely
mounted by the client trying to access it.
-- 
Name:			Christopher J. Calabrese
Brain loaned to:	AT&T Bell Laboratories, Murray Hill, NJ
att!ulysses!cjc		cjc@ulysses.att.com
Obligatory Quote:	``Anyone who would tell you that would also try and sell you the Brooklyn Bridge.''