dhinds@portia.Stanford.EDU (David Hinds) (11/03/90)
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. Now, the job seems to still be running. What is going on? Does the OS still have a link to the deleted file somewhere? Will the program crash if the OS has to fetch a page from the executable at some point? 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? -David Hinds dhinds@cb-iris.stanford.edu
brendan@illyria.wpd.sgi.com (Brendan Eich) (11/05/90)
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
MOHRINGJ%ESVAX@dupont.COM (11/06/90)
In Message-Id: <9011041649.AA25370@snow-white.merit-tech.com>
Mike Goss writes;
Not to worry; you can't delete a file in Unix until it's good and ready
to let you delete it. Unlike most operating systems, Unix does not
actually have a file delete operation. When you think you are deleting
a file, you are really only unlinking it.
Does this mean there is a way of recovering a file you "rm" only
to find out it was a really big "OPPS!!" in doing so?
Jim Mohring
DuPont Experimental Station
Node: mohringj%esvax%dupont.com
Phone 302-695-4325
FAX 302-695-1173
"Silence is the ONLY acceptable substitute for Brains"