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, even though 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.