Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!pyramid!prls!mips!dce
From: dce@mips.COM (David Elliott)
Newsgroups: comp.unix.wizards
Subject: Re: Symlinks vs. NFS
Message-ID: <2378@quacky.mips.COM>
Date: 14 Jun 88 13:57:42 GMT
References: <2372@quacky.mips.COM>
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 24

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