Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.wizards
Subject: Re: Demand paged executables
Message-ID: <8862@alice.UUCP>
Date: 3 Feb 89 16:58:58 GMT
References: <409@lakart.UUCP> <7599@chinet.chi.il.us> <6211@saturn.ucsc.edu>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 32

In article <6211@saturn.ucsc.edu> brad@polaris.UUCP (Brad Smith) writes:
}Two questions/points on this:
}	- Wouldn't there be some problems with other links to
}	  a file being invalidated (pointing to the old version)
}	  if the file was unlinked, a new inode allocated, and
}	  a new link created to copy over an executing program?

If you try to write over an existing file that is being executed that should
fail. You can remove the file and create a new one, but indeed all other
links to the old file will still point to the old file. If your system
supports them it is better to use symbolic links to executable files, to
avoid ending up with multiple versions of programs that once were the same.

}	- It seems the reason for not locking shell scripts is
}	  that virtual memory for the executable is not being
}	  paged out of the file containing the script.  Some
}	  program (typically a shell) is being run with the
}	  contents of the script as input... or something to
}	  that effect.

The shell only reads and interprets the shell script. The script does not
contain machine-code. The shell does not read the whole script before
executing it however, so when you change a large script while it is being
executed (i.e. read) the shell may find syntax errors because it suddenly
continues to read the new script from an arbitrary point (a block boundary
usually).

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------