Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!oliveb!3comvax!bridge2!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Demand paged executables
Message-ID: <927@auspex.UUCP>
Date: 1 Feb 89 19:34:22 GMT
References: <409@lakart.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 34

>There is doubtless a good reason for it,

No, not really.

>but why is it not possible to unlink a demand paged program that is
>executing.

It has nothing to do with demand paging.  In fact, V7 imposed this
restriction, and as distributed by AT&T, V7 didn't support demand
paging.  4.xBSD *does* support demand paging, and Berkeley *removed*
this restriction because it was dumb.

>I realise that the system needs to keep the program text somewhere, but
>why can it not do the same as is done with a normally open file: just
>remove the directory entry, but hang on to the I-node and disk blocks
>until such time as the process execl()'s or exit()'s. I am probably missing
>something,

No, you are not missing anything.  You are 100% correct.

The "reason", as I'd heard it, is that they didn't want to have files
with no links lying around after a crash, and if they let you unlink a
file while it's running, and the system crashes before the last process
running that program exits or "exec"s some other program, the file for
that program will be such a file.

It is left as an exercise to the reader to figure out why the
restriction in question won't make this "problem" go away.  (Hint: the
original poster's argument applies here, too....)

The correct way to deal with those files is to use a file system
salvager better than the abysmal "icheck" and "dcheck" that came out
with the original V7; "fsck", fortunately, appeared on an addendum tape
to V7, and will clean up files such as that quite nicely.