Xref: utzoo comp.unix.i386:2827 comp.unix.questions:19733 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.i386,comp.unix.questions Subject: Re: Demand paged executables. Keywords: rm Message-ID: <2912@auspex.auspex.com> Date: 7 Feb 90 18:16:08 GMT References: <134@fts1.UUCP> Followup-To: comp.unix.i386 Organization: Auspex Systems, Santa Clara Lines: 30 > I've found, what I would consider to be a silly design decision on either >AT&T (or possibly ICS). (One of many.) It's AT&T's fault.... > Why should this happen? No good reason whatsoever. >What is wrong with simply locking the inode internally, (so that the file >doesn't disappear), but drop the link count to zero. Nothing is wrong with it; in fact, UNIX has done that since V6, I think, so there are no changes needed to implement that, other than removing the check in "unlink" for files currently being used as shared text files. >How is this at all different from: It's not different in any way. >I believe that BSD 4.3 (Or, at least, SunOS 3.0+, I never used anything >below that.) will let me do that type of thing. You believe correctly. That particular bogosity was in V7 from AT&T - no, it wasn't stuck in in System III or System V, you can blame the folks in Research for that one - and Berkeley ripped it out, probably in 4.1BSD or even earlier. It may, with any luck, be gone in S5R4.