> so if I run the program at , say, 9AM
> then copy a new version of the program
> into the old program name & location on disk
> and then rerun the program.
> It will run the old version since it is still
> in memory from the first run.
> Or does it check the disk to make sure
> the file it used originally to load the
> program hasn't changed, and then reload
> the program as the new version.
Assuming NO OTHER SYSTEM ACTIVITY, a proper
merged VM/Buffer cache system will still have the copied
contents of the new file in memory. The new file information
will also still likely be in memory, so the number of disk accesses
due to running a new program should be nil. On a totally
standard POSIX system, with perfect caching, the only real
I/O will be to eventually update the access times, etc. The old file
buffers will either be over-written by the file modification, or
the old file buffering will have been deleted by a file deletion
before creation of the new copy. (This depends upon the
filesystem semantics and the user program behavior.)
If the disk drive is shared (through locking protocols), then there
might be a need to re-read the file (depending upon system network
activity.) This doesn't appear to be the circumstance that you are
asking about, however.
One major key to maximum system efficiency is to make sure that
use of memory doesn't compete too much against the file caching. Also,
it is important to make sure that I/O or copying isn't necessary to
make a newly created executable program into a runnable entity. (*Of course,
there are times where semantics might require this -- e.g. networked
environments with robust program behavior.)