Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site usc-oberon.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ucbvax!hplabs!sdcrdcf!usc-oberon!tli
From: tli@usc-oberon.UUCP (Tony Li)
Newsgroups: net.decus
Subject: Re: Nifty feature in VMS alias mechanism
Message-ID: <713@usc-oberon.UUCP>
Date: Sun, 10-Aug-86 16:10:23 EDT
Article-I.D.: usc-ober.713
Posted: Sun Aug 10 16:10:23 1986
Date-Received: Thu, 14-Aug-86 07:06:54 EDT
References: <486@batcomputer.TN.CORNELL.EDU> <1000@ttrdc.UUCP>
Reply-To: tli@usc-oberon.UUCP (Tony Li)
Organization: USC Computing Services, Los Angeles, CA
Lines: 19

In article <1122@ttrdc.UUCP> levy@ttrdc.UUCP writes:
    (Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY
    under VMS if DELETE-ing the extra entry blows away the file data itself,
    leaving any other entries for that file invalid?  Why isn't a link count
    kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?)

SET FILE/ENTRY in VMS is a serious kludge and is not meant to be used in cases
where one entry might be deleted.  There is no link count, and there are no
inodes to speak of.  There is an index to the system and the link count
could be kept there....  but it's not.  Basically, SET FILE/ENTRY is a very
dangerous feature which is not properly supported.


-- 
Tony Li ;-)		Usc Computer Science
Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli
Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth
Csnet: tli@usc-cse.csnet
Arpa: tli@usc-ecl.arpa