>>> In regards to overwriting existing binaries which might be in use,
>>> whatever happened to "Text file busy"?
>> IMO it wouldn't [be useful].  That would prevent the installation of
>> that binary; in this circumstance I _want_ to replace init.
> ETEXT doesn't mean you can't rename() the thing, it just means you
> can't re-write it.  Essentially it enforces the approach of "if it's
> busy, don't copy onto it, or Bad Things Will Happen (TM)."

Right.  But as I understand it, having ETXTBUSY in place wouldn't
affect things, because install is blowing away the (link to) the old
binary before installing the new.  (It may do this atomically with
rename() - I haven't been able to find the source to install.)  So
"Text file busy" errors wouldn't occur in any case, and the original
problem - ie, something doesn't like having inodes hanging around
without filesystem names for them - would still be present.

> [What were the rules for ETEXT again...?  You can have it open for
> writing or executing, but you can't have it open for both, and read
> permission is immaterial.  Or something like that.]

Something like that, except I think it's that when you try to open for
write, if the file is backing a text segment that's in use, you get
ETXTBUSY.  I don't recall anything that would prevent executing a file
that's still got a file descriptor open for write.  (But on the other
hand, the last source code I looked at this under was 4.3BSD.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu