How to find process name in c?

Guy Harris guy at auspex.auspex.com
Thu Jul 19 04:49:40 AEST 1990


>Where does this happen, what kind of Unix?  I have overwritten
>executable files that are currently running under various revisions of
>BSD, SunOS, even VMS, without ever getting errno ETXTBSY.

Err, you *are* aware that VMS is not any "kind of Unix", and as such
1000% irrelevant here, right?  (Yes, I know there is some amount of UNIX
compatibility supplied with VAX C or something like that; that doesn't
count, and things like EUNICE don't count, either.  Neither do DEC's
plans to make VMS POSIX-compliant; POSIX doesn't specify ETXTBSY.)

I'm quite surprised to heard you've never gotten that error under BSD.
I'm not surprised you've not gotten it under SunOS, at least if it was
SunOS 4.x, as SunOS 4.x never returns ETXTBSY.

In addition, earlier releases of SunOS may not have done the check for
NFS-mounted file systems, even if the program was running on the same
machine on which the open for writing was done (I know it didn't do any
checking if they happened on different machines); if the BSD you were
running was one with NFS added to it, that might explain how you managed
not to get ETXTBSY under BSD.

(You *are* speaking of *overwriting* the executable file, not unlinking
it and copying a new one in, right?  The BSD "install" script unlinks
the target and then copies a new version in, which avoids the problem. 
BSD, unlike System V, does not continue the stupid V7 tradition of
disallowing removing the last link to a busy text file....)

>After the image is loaded into core, why should the OS care what you do
>to the copy still on disk?

In most modern versions of UNIX the image isn't necessarily "loaded into
core"; it's often demand-paged from the "copy still on disk".

>ETXTBSY is not even listed in the `Errors' section of the SunOS `open'
>man page.

You have 4.x, then.



More information about the Comp.unix.questions mailing list