Bad interaction between mmap and busy text files.

[Guy Harris]

>	In SunOS, programs like "cp" use mmap, which succedes in
>	overwriting the busy text file, usually aborting the executing
>	instance of the first program.

This has nothing to do with "mmap"; try it with "dd", which doesn't use
"mmap".  (In fact, "cp" uses "mmap" only on the *input* files; it does a
"write" to the output file, writing from the mapped-in area.)

>	My intuition is that mmap should return ETXTBSY in this case
>	instead.

In what case?  Trying to map a shared-text file read-write? The "right"
place to to catch that might be "open"; however, SunOS 4.0 doesn't have
"shared texts", so that's a little hard.  What are, in other flavors of
UNIX, "shared texts" are in 4.0 just copy-on-write mappings to a file -
the copy-on-write part allows you, for example, to run a debugger on a
program that's being run by others, since the breakpoints get set in
private copies of the pages on which they're being set. 

Other extremely similar copy-on-write mappings include mappings to shared
libraries, and you *have* to be able to map them read-write, since PIC
isn't 100% PI and some relocation has to be done.

The only real fix to this would be to arrange that modifying a page that
has a shared writable mapping to a file causes the copy-on-write feature
to be triggered on all copy-on-write mappings to that page; I don't know
whether this change to the semantics of "mmap" would break anything else,
or be a "surprising" change, and I don't know how difficult it would be.

>	I only tried this with local disks.  Who knows what NFS will do?

It'll do the same thing.  In fact, even prior to 4.0 you could modify a
file that machine A had mapped in as a shared-text segment, as long as you
did it on a machine other than machine A, i.e., either the server or
another of its clients.