Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!pesnta!epimass!jbuck
From: jbuck@epimass.UUCP (Joe Buck)
Newsgroups: net.decus,net.unix
Subject: Re: Nifty feature in VMS alias mechanism
Message-ID: <373@epimass.UUCP>
Date: Mon, 11-Aug-86 00:37:29 EDT
Article-I.D.: epimass.373
Posted: Mon Aug 11 00:37:29 1986
Date-Received: Tue, 12-Aug-86 12:59:00 EDT
References: <486@batcomputer.TN.CORNELL.EDU> <1000@ttrdc.UUCP>
Reply-To: jbuck@epimass.UUCP (Joe Buck)
Organization: Entropic Processing, Inc., Cupertino, CA
Lines: 19
Summary: VMS could easily do links properly (like Unix)
Xref: mnetor net.decus:369 net.unix:5171

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?)

VMS does have the equivalent of inodes; they're blocks in the index
file, pointed to by the FID.  The index file looks very much like the
inode list of Unix.  It would take very little work to add a link
count to the index block and change $DELETE to Unix behavior.  There
are a couple of barriers to making the behavior identical -- for one
thing, the filename (but not the directory name) is stored in the
index block, but this is mostly relevant when a lost file is
recovered (because, say, a user blew away a directory entry with SET
FILE/REMOVE).  But VMS could handle links properly without that much
effort, and users wouldn't notice the change.
-- 
- Joe Buck 	{ihnp4!pesnta,oliveb,nsc!csi}!epimass!jbuck
  Entropic Processing, Inc., Cupertino, California