Xref: utzoo comp.unix.i386:2861 comp.unix.questions:19783 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!mit-eddie!bu.edu!bu-cs!lectroid!jjmhome!cpoint!frog!john From: john@frog.UUCP (John Woods) Newsgroups: comp.unix.i386,comp.unix.questions Subject: Re: Demand paged executables. Keywords: rm Message-ID: <11909@frog.UUCP> Date: 8 Feb 90 01:30:00 GMT References: <134@fts1.UUCP> Followup-To: comp.unix.questions Organization: Misanthropes-R-Us Lines: 20 In article <134@fts1.UUCP>, michael@fts1.UUCP (Michael Richardson) writes: > I've found, what I would consider to be a silly design decision on either > AT&T (or possibly ICS). (One of many.) > fts1-(~/filedep ) 16 =>: rm uniqserv > uniqserv: 755 mode ? y > rm: uniqserv not removed. > Text file busy > fts1-(~/filedep ) 17 =>: >Why should this happen? What is wrong with simply locking the inode internally, >(so that the file doesn't disappear), but drop the link count to zero. The answer is: history. It's always been done that way. There's no particular reason it needs to be that way, and UNOS (for instance) gets by quite happily allowing the removal of active program files. It also happens to be easy to allow writing to active program files IF it isn't a demand paged executable. -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu