VMS vs. UNIX file system

[Chris Torek]

In article <1986 at bucsb.UUCP> jbw at bucsb.UUCP (Joe Wells) writes:
[ASTs and stack unwinding are nice: agreed, although 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.  (Note that you can
implement this yourself if you have the full-blown general mechanism.)
But neither of these have anything to do with the file systems:]

>Directory links under VMS are not necessary for a file to exist.
>Under UNIX, when all the links to a file disappear, and all processes
>close the file, the file is deleted.

(Easily argued to be the correct behaviour.)

>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.

>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.  Sounds like a point *against* VMS to me.  (Not entirely
so: someone linking to your files can keep you from deleting them when
you had intended to.  This problem does not seem to occur often in
practise.)

Unix has its weak points, but its file system is not one of them.
-- 
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