| Date: | May 10, 2013 / year-entry #128 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20130510-00/?p=4403 |
| Comments: | 20 |
| Summary: | 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... |
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. |
Comments (20)
Comments are closed. |
Or simpler, stop naming the file mapping if you didn't have a good name in the first place.
People just love using named objects with no reason. Because it's pretty? And when their program fails or misbehaves because of that, they get very surprised.
This is functionality that I am entirely unfamiliar with. Assuming that henke37's comment is valid, it sounds like the customer really just wants file mappings and went about it by following some example that did it the wrong way. Just let the system generate a unique handle for your mappings and retrieve them using that. Why create a customized name for it if the name is arbitrary? This is all subject to the idea that this is even possible (I have no idea).
I suspect that if you can use a GUID to name your object, you probably don't need to name your object. The whole point of choosing a well-known name is so that other applications can use the same object without having to communicate the name.
If you can communicate the name, you can probably just duplicate the handle and communicate the new handle.
That's not to say there aren't times when it's a good idea to make a unique name for an object, but they're certainly pretty rare.
The point of naming a file mapping (semaphore/event/mutex/…) is to have a common name between processes. E.g. Program1 + Program2 want to share some memory over which they want to communicate. Now to get a unique name, just create a GUID, compile this into both programs and use it as the name for the file mapping. After this, you don't need to duplicate a handle or communicate over some other interprocess communication path.
This approach works even better when you want to build a service which wants to hand out some shared memory for each connecting application. Just create a new GUID for each client, and hand the guid to the client. You can have 'unlimited' clients and don't worry about curious naming schemes.
The point of this post is, don't name your file mapping "C:&t.txt", because some component might have the same idea.
@Joshua
You may give an object a name, but you don't have to. If you don't use the object across process boundaries, you really shouldn't.
Well, if nobody should do it, then I'm the only one doing it, there shouldn't be a collision, right?
Couldn't you just give it some kind of namespacing style name so you know it's not being used outside of your organization? Then if someone else names their file mapping Com.MyCompany.MyFileMapping or whatever, it's kinda their fault.
I know, I'll ROT13 the filename. And then I'll ROT13 it again, just to be on the safe side.
BZ: Exactly my thoughts on the matter.
Maurits: Are you aiming for a manager position at Adobe? ;-P
Grr!
Pet hate: the collection of letters "prepending" – it's NOT a word. Try "prefixing" – it's one keystroke shorter, it's clear, and it has a valid antonym: "suffixing".
I like the idea of combining a GUID with the filename – gives uniqueness, but retains the link to the filename (if that's required). Always assuming you need a name (and the "sharing between two processes" reason is sufficient).
Wombat said at 12 May 2013 3:52 PM:
My dictionary disagrees.
"Appending" is not a clear, valid antonym?
@Wombat, R. Cranium:
My dictionary also disagrees, but my other dictionary thinks it means something else:
1) Definition of PREPEND
2) prepend definition
jargon
/pree'pend'/ (by analogy with "append") To prefix or add to the beginning.
but in practice MS uses file path (and only file path) when creating mapping for several index.dat-s
If different applications open the same file for mapping without naming the mapping object, it will create a coherent view to the file anyway. It needn't be the same named mapping object.
Giving the file mapping object – or any kernel object – a name can be useful when post-mortem debugging, to identify exactly *which* object you happened to be deadlocked on (for example). I've certainly seen recommendations that you name all kernel objects, for this reason.
@Richard Cranium
My point was that prefix / suffix are a complete pair, whereas append has no (real) antonym. Yes, prepend is attempting to enter our language as a *** sibling (or as one of the dictionaries quoted phrases it: "by analogy"), but there's no need for it when we have a perfectly good word already in existence.
Did I mention this was a pet hate? :-)
@alegr1
The views are coherent under quite specific conditions (listed carefully in the discussion) – it is possible for them not to be coherent.
@Mike Dimmick
That's why I like to see the name reflect the target in some clear way. One could just use a GUID by itself, but that loses the connection, and one might just as well not name the object.
@Wombat:
Coherency is not guaranteed only between mappings in two different remote systems. All mappings of the same (local or remote) file on a given system are coherent.
A separate namespace for file mappings? What part of System V IPC convinced you this was a good idea?
When I want to insert something unique to a process in a name, I tend to use the process or thread ID (and if it may outlive the process, I toss in the creation time and hope/enforce that the process may live one millisecond longer).