Path: utzoo!utgpu!watserv1!watmath!att!att!rutgers!cs.utexas.edu!sdd.hp.com!mips!prls!pyramid!decwrl!sgi!brendan@illyria.wpd.sgi.com
From: brendan@illyria.wpd.sgi.com (Brendan Eich)
Newsgroups: comp.sys.sgi
Subject: Re: Strange pmake behavior
Message-ID: <74115@sgi.sgi.com>
Date: 5 Nov 90 02:44:55 GMT
References: <1990Nov2.223533.8694@portia.Stanford.EDU>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 49

In article <1990Nov2.223533.8694@portia.Stanford.EDU>, dhinds@portia.Stanford.EDU (David Hinds) writes:
> Something bad just happened to me, but I can't tell exactly how bad it is.
> I was rebuilding a large program after making a minor modification, with
> pmake.  When it got to the point of trying to link the executable, I realized
> that it was going to fail because the text file was busy - I was running
> the previous version of the program in the background.  So, I interrupted
> the make with control-C.  Pmake then proceeded to delete the file it was
> last trying to make - the busy executable!  This seems to me to be a poor
> way of dealing with the signal, to put it mildly.

Make would have done the same, as would any *make program that emulates
original make's feature of unlinking non-precious targets upon receipt of
the interrupt and quit signals.  Unlinking the target of an aborted make
avoids leaving incomplete garbage linked under the target name, which would
fool make into thinking the target is up to date (just because it exists).
If you want make to leave certain targets linked, add them as dependencies
of the .PRECIOUS: built-in target.  All the man pages (make(1), pmake(1))
document this feature.

> Now, the job seems to
> still be running.  What is going on?  Does the OS still have a link to the
> deleted file somewhere?

No link in the filesystem (you removed the last one), but there is still
a reference to the in-kernel data structures needed to execute the program.
Irix 3.3, along with SunOS and 4.3BSD, allows unlink(2) of an executing file
but not truncation (creat(2), open(2) with O_TRUNC, truncate(2)) or write(2).
Older versions of Unix fail unlink of an executing program's file, for some
not-so-compelling reasons.

> Will the program crash if the OS has to fetch a
> page from the executable at some point?

No.  Have you ever dealt with a similar Unix feature (this one goes back
to the dawn of time), open-unlink?  If you open a file and unlink it, you
can nevertheless write and read it.  The OS does nearly the same when it
needs to read a page from the unlinked, executing file.

> This is a LONG job - I expect it
> to run for two weeks - so I don't want to get a core dump when this is
> all over.  Any ideas?

Sounds like a feature.  You must have intended to destroy the file that
was (is?) executing when you typed 'pmake' (ld would eventually overwrite
it, which would fail with ETXTBSY on any variant of Unix).  Interrupting
pmake saved you from this and other misfortunes by unlinking the target.
In no case would the original file have persisted across the make.

/be