Xref: utzoo comp.unix.i386:2788 comp.unix.questions:19696 Path: utzoo!dciem!nrcaer!fts1!michael From: michael@fts1.UUCP (Michael Richardson) Newsgroups: comp.unix.i386,comp.unix.questions Subject: Demand paged executables. Keywords: rm Message-ID: <134@fts1.UUCP> Date: 1 Feb 90 21:00:18 GMT Organization: Fountain Technical Services, Ottawa, ON Lines: 44 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. How is this at all different from: fd=open("/tmp/mytemporary",somemode); unlink("/tmp/mytemporary"); /* do lots of neat things with fd */ /* If I die a horrible (SIGKILL) death, my temporary file will be */ /* removed */ This is under Interactive 386/ix, a SVR3.2 port. I can understand why the kernel might not want anyone to open the file for writing (thus ld fails), but can see no reason why the name of the must continue to exist. (I can rename it just fine...) 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. And I guess if it doesn't let me do that, I could easily just remove the file from another station across the network. Presumably, the process would die a horrible death, but caveat-user. [Actually, I guess generation numbers come into play on this.] -- :!mcr!: Michael C. Richardson HOME: mcr@julie.UUCP SCHOOL: mcr@doe.carleton.ca WORK: michael@fts1.UUCP I never liked staying in one place too long, but this is getting silly...