VMS vs. UNIX file system

[Guy Harris]

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

Well, maybe.  (The Xerox Pilot file system works this way also, I believe.)
There may be cases where you want a file to have references to other files, but
where the referencing file is more than just a list of referenced files; this
might be a case where "open by file ID" could be a win.  You can do this in
UNIX, using the file's pathname - full, or relative to some particular
directory if referenced files are always stored there - as the ID in question.

Of course, there are problems with doing what, as you observe, more-or-less
amounts to setting up your own directory mechanism.  One of them is that you
have to set up your own directory mechanism; since VMS doesn't maintain link
counts, you would at least not have to do this yourself.  Another is that if
somebody makes a new file and does the moral equivalent of an "mv" to replace
the referenced file with that file, you lose; this may be a feature in some
applications, and a bug in others.  (We won't discuss the issue of editing
the referenced file - named, say "DKn:[...]FILE.DAT;33" - to get
"DKn:[...]FILE.DAT;34", but having the file that references the file still
refer to "DKn:[...]FILE.DAT;33"; again, this could be a feature in some
instances or a bug in others.

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

No, he said

	When the VMS equivalent of the UNIX inode is reused, a counter in the
	index table slot is incremented.  Thus any dangling pointers to the
	previous file that used the same slot won't have any effect.

which is, of course, a problem in UNIX *only* after a crash, and then only if
you don't run "fsck" to fix things.  (VMS's predecessor, RSX-11M, had its moral
equivalent of "fsck", and I suspect VMS has it as well.)  I would not classify
this as a real problem; it isn't *supposed* to happen, and there are standard
procedures for fixing it.

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

I agree.  The lack of reference counting in Files-11 doesn't strike me as
unambiguously being a feature, and the ability to open files by unique ID may
not necessarily be a winning feature if, for instance, you have to give up
reference counting for it.