Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!gatech!ncar!tank!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: VMS vs. UNIX file system Message-ID: <13562@mimsy.UUCP> Date: 15 Sep 88 00:12:48 GMT References: <411@marob.MASA.COM> <178@arnold.UUCP> <1986@bucsb.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 38 In article <1986@bucsb.UUCP> jbw@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 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@mimsy.umd.edu Path: uunet!mimsy!chris