Holy cow, I wrote a book!
The original question from the customer was why they couldn't
get named file mappings to work at all,
but it turns out that the reason is that
they were using the full path to the file as the name,
backslashes have special meaning in file mapping names.
Okay, that problem can be solved by changing the backslash
to some character legal in file mapping names but
not legal in file names; say, a question mark.
But that only solves part of the problem:
Getting the name past the object manager.
The next problem is in the answer to the question,
What if two programs did this?
If two programs did this, then they would end up stepping on each
other's file mapping objects.
Maybe your program creates the file mapping objects read-only,
but the other program creates them read-write.
Or you create them with default security, but the other program
creates them with custom security.
Or you create the mapping for only the first megabyte of the file,
whereas the other program creates the mapping on the entire file.
The point is that by choosing such an obvious name,
you may collide with somebody else who chooses the same obvious name,
even though each of you think that you're the one who came
up with a name so clever nobody else could possibly have thought of it.
If you're going to use a named object,
you need to choose a name that is unlikely to collide with names
chosen by others.
And naming something after its own path is probably going to collide.
You should throw something into the mix that makes the string unique,
say, prepending your
Application User Model ID
or a GUID to the name.