VMS vs. UNIX file system

Joe Wells jbw at bucsb.UUCP
Fri Sep 16 02:40:07 AEST 1988


In article <13562 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>... I think ASTs
>are `too complicated' for general use, by which I mean there should
>be a nice simple method of just getting several syscalls going at
>the same time ... e.g., lightweight processes.

Agreed.  Having separately scheduled tasks each with its own stack is
really the best way.

>>In VMS, a file can exist without a name.  It can be accessed by its
>>unique file identifier.
>
>Presumably a `unique file ID' is like a Unix <dev,inode> pair.  How
>does one construct a file ID once the names are gone?  Search the disks
>directly for IDs without names attached?  Store the IDs in another file?
>(Then that file is a directory, so why not use a real directory?)
>This really sounds more like a bug than a feature.

Yes, in VMS it's not really well thought out.  One use is for temp
files, which you have to mark as "delete on close".  Another use is
for more quickly opening files.  Opening by file id is much quicker.
This can be useful when you have a directory with 10,000 files in it.
But yes, you have to remember the file ids in *another* file ...

>>In addition, the problem of dangling directory links to deleted files
>>does not exist.
>
>`The problem of dangling directory links to deleted files'?  If you
>mean that I can remove a file that you depend upon, even though you
>have an alternate name for that file: that does not happen in Unix,
>only in VMS.

This problem can occur every time a UNIX system crashes.  A entry in a
directory file can point to a inode whose file has been deleted.  Then
when the inode is reused, it has two links, but a link *count* of one.
That is why fsck is run every time a UNIX system boots.  Under VMS,
the directory entry would have a file id.  The file id would still
point to a slot in the file index table, but its use count would be
different from the count in the table.  So it would simply be an
invalid link.

I don't think the ability of a file to exist without a directory entry
is an advantage.  However, I like the ability to open a file without
knowing a name for the file.  In UNIX such a feature would require
rethinking file security since a directory's priveleges are used to
protect files inside it.

>Unix has its weak points, but its file system is not one of them.

Its simplicity is its strength, in my opinion.

>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
>Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris

Joe Wells
INTERNET: jbw at bucsf.bu.edu
UUCP: ...!harvard!bu-cs!bucsf!jbw



More information about the Comp.unix.wizards mailing list