Demand paged executables.

[Michael Richardson]

  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 at julie.UUCP SCHOOL: mcr at doe.carleton.ca WORK: michael at fts1.UUCP
I never liked staying in one place too long, but this is getting silly...