michael@fts1.UUCP (Michael Richardson) (02/02/90)
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...guy@auspex.auspex.com (Guy Harris) (02/08/90)
> 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.
john@frog.UUCP (John Woods) (02/08/90)
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