Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.wizards
Subject: Re: rm etc. (was: Nasty Security Hole?)
Message-ID: <8094@bloom-beacon.MIT.EDU>
Date: 21 Nov 88 05:12:29 GMT
References: <175@ernie.NECAM.COM> <8941@smoke.BRL.MIL>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 21

In article <8941@smoke.BRL.MIL> gwyn@brl.arpa 
 (Doug Gwyn (VLD/VMB) <gwyn>) writes:

>All implementations of "symbolic links" that
>I know of are broken in this regard; even though symbolic links to an
>inode exist, the inode will vanish when all its "hard" links are
>removed (and the last open file table entry associated with it is closed).

I don't count this as a bug; it can be quite useful.  For example, hard links
must be to the same device.  An implementation of symbolic links that had the
destiniation be an inode would be indistinguishable from a hard link (at least
in 4.3, symbolic links point to filenames [or, in fact, any string that could
possibly be a filename]).  There is no way to guarantee that all symbolic 
links to a filename are on mounted filesystems, so it is not reasonable to 
have their existence influence unlinking.

--
   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
   bloom-beacon!          Will they read of us with sadness
   athena.mit.edu!jfc     For the seeds that we let grow?"  --Neil Peart