Should I name my file mapping after the file it was created from?

Many times a customer creates a file mapping object and assigns it a name that matches the name of the file it was created from. Mind you, there needs to be some fiddling with the name because backslashes are not allowed in object names (aside from the Local\ or Global\ prefix), so typically people change backslashes to forward slashes, resulting in file mappings named, for example C:/path/path/path/file.txt.

Is this a problem?

First, let's put on our kernel-colored glasses.

From the kernel's standpoint, there's nothing wrong with this. You can name your file mappings anything you want. You can name them after the file they were created from. You can name them after your cat. You can give them a misleading name. The kernel doesn't care, as long as you give a legal name. So sure, go ahead and name your file mapping after the file it was created from.

Okay, let's take off our kernel-colored glasses and look at the bigger picture.

Suppose you name your file mapping after the file it was created from. And suppose somebody else does the same thing. Now you have a name collision. Your attempt to create a file mapping will succeed but also report ERROR_ALREADY_EXISTS, to indicate that instead of creating a new file mapping, the system gave you an existing one with that name.

The catch is that the file mapping the system gave you may not be the one you want. It may have been created with the wrong security attributes, or created with the wrong page protection, or created with the wrong size. (And by "wrong" I mean "with values that are different from what you expected.")

That's the thing about sharing a namespace with others: If you give your objects too obvious a name, somebody else may choose the same obvious name. We've seen this before in another context.

But let's step back again: Why are you giving your file mappings names? Do you really intent to share them? Or are you just giving them names because it's nice to give names to things? You can name your car, and you can name your kernel objects, but there is a qualitative difference between the two.

If you don't intend the file mapping to be shared, then don't give it a name. Giving it a name means that you intend to share it, and the name is how people can access the shared handle.

If you really do intend the file mapping to be shared, say, with other instances of the same program, then you should use a name that only your program uses. For example, you could prefix a fixed GUID to the name, so that all file mapping names used by your program have the form {guid}-C:/path/path/path/file.txt. Since only your program uses that GUID, it won't conflict with names used by other programs.

(You can think of prefixing the GUID to the mapping name as a poor man's way of creating a namespace.)

Comments (11)
  1. Mason Wheeler says:

    Poor Man’s Namespaces.

    That would be a fun band name…

    1. Brian_EE says:

      Is that a band name that is fun, or a name for a fun band? Your comment is ambiguous.

      1. French Guy says:

        Why not both?

    2. pc says:

      Would be better if you prepended a GUID.
      {ce5e3430-bd90-11e7-909f-00a0cc7c5f97}-Poor Man’s Namespaces is a much better name.

      1. yukkuri says:

        Makes me giggle imagining news media trying to handle that, in light of the circumlocutions they used when Prince changed his name to that glyph

    3. bmm6o says:

      Why give your band a name at all? You’re just inviting unnecessary ERROR_ALREADY_EXISTS errors.
      Ooh! Name your band “ERROR_ALREADY_EXISTS”!

      1. Scarlet Manuka says:

        You probably want your band to be shared (on social media at least), so you should give it a name.

        1. skSdnW says:

          No, a private party is much better. Hand out the tickets with DuplicateHandle.

          1. Brian_EE says:

            Just use 09F911029D74E35BD84156C5635688C0 for the name.

  2. Jan Ringoš says:

    Also there’s the length issue where kernel object names are limited to 255 characters but file system paths can be up to (slightly less than) 32767 characters. If I needed something like that I would probably just use hexadecimal representation of dwVolumeSerialNumber and nFileIndex(Low|High) retrieved from BY_HANDLE_FILE_INFORMATION.

    1. florian says:

      That’s what I would use, too. In a recent post, Raymond has recommended to use Get­File­Information­By­Handle­Ex() to get the full 128-bit File­Id­Info on ReFS.

Comments are closed.

Skip to main content