Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <68453@sun.uucp> Date: 15 Sep 88 03:09:34 GMT References: <411@marob.MASA.COM> <178@arnold.UUCP> <1986@bucsb.UUCP> <13562@mimsy.UUCP> Sender: news@sun.uucp Lines: 51 > Presumably a `unique file ID' is like a Unix 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.