Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uunet!peregrine!ccicpg!felix!hplabs!ucbvax!ulysses!hector!ekrell
From: ekrell@hector..UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links are a botch
Message-ID: <2654@ulysses.homer.nj.att.com>
Date: Fri, 12-Jun-87 20:43:21 EDT
Article-I.D.: ulysses.2654
Posted: Fri Jun 12 20:43:21 1987
Date-Received: Sat, 20-Jun-87 21:02:24 EDT
References: <7724@brl-adm.ARPA> <6233@steinmetz.steinmetz.UUCP>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@ulysses (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 28
Keywords: symbolic link

In article <6233@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes:

>Problems:
>  a) permissions - ignore, new meaning, ?
>  b) loops?
>  c) links to files, directories?
>  d) links to FIFOs (this is SysV)

I don't see how these things are related to the treatment of ".." in a different
way. If this are general arguments against adding symbolic links to System V,
then the answers are:

a) You need read permission on the symbolic link itself and then whatever
   permissions you require are matched against the file/directory/whatever
   the link is pointing to.

b) The kernel as a built-in limit on the number of symbolic links it can
   expand while translating a given pathname. This handles loops.

c) Yes, yes.

d) Why not?. A Symbolic link is an abstraction that can point to anything.
   The idea is to extend the hard link mechanism to allow for links to
   cross file system boundaries.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell