How to create a file mapping that allows others to open the file in exclusive mode?


A customer had a tool that opens files like DLLs and TLBs in order to extract information from them.

We currently use Create­File, Create­File­Mapping, and Map­View­Of­File to access the file. The problem is that the Create­File­Mapping prevents the file from being renamed or deleted, even if the Create­File opened the file with a sharing mode that permits those operations. It is our understanding that this is expected behavior.

Since DLLs and TLBs under active development are frequently deleted or overwritten, our use of Create­File­Mapping interferes with developer workflow because the user's build will fail with a sharing violation. We were wondering if there is an alternative to Create­File­Mapping that would allow the file to be renamed, deleted, or written to. We know that we could slurp the entire file into memory and operate on the in-memory copy, but we were hoping for something less drastic.

Yes, there is something less drastic. In fact, this is the type of scenarios for which opportunistic locks were created: You want to access a file, but you don't want your access to interfere with anybody else who wants to access the file after you get access.

For a code sample, I defer to my earlier discussion of opportunistic locks.

Comments (9)
  1. Killer{R} says:

    But Create­File­Mapping doesn’t prevent file from being renamed.

    1. Joshua says:

      Indeed, and I take full advantage of this to overwrite running DLLs. Now if I could only figure out how to delay a delete w/o admin rights …

      1. Killer{R} says:

        I had a code that does this.. But Raymond will not allow to share it, cuz that code is a whole hack:)
        But I may try to share the idea. The idea is to enumerate&remember all pages belonging to dll’s view, then unmap that view with UnmapViewOfFile, then immediately allocate memory (or better map pagefile-backed view) in same place and fill it with remembered content, reverting pages protection. Of course no one thread should be executing dll’s code at that time and code that doing all that should be somewhere out of it… And even then this may cause problems, for example if somebody will try to use GetMappedFileName on address beloning to dll’s view.

  2. DWalker says:

    They are going to extract information from files that might be in the process of being overwritten… Hmm…. Well, nothing in the world is ever static for long.

  3. alegr1 says:

    Just a few days ago I was investigating a problem.

    As you may have heard, previous Windows version loaded the driver images to the page file and didn’t keep the image file open. Pageable sections were read from the page file.
    Windows 10 (Server 2016) now uses the original image file to back the pageable sections. Obviously, a thought of wasting 5 MB (5 minutes of MP3 or a couple of photos) of page file was bothering someone too much. Or that someone wanted a promotion.

    Now the fun part. File mapping objects created with SEC_IMAGE flag allow to delete or modify the file after the original file handle is closed. This is the flag used to create objects for loadable images. Even though the file mapping exists, if the file is deleted, the page-in will only bring zeros. If the file is overwritten, the page-in will bring new code (or some data as code).

    For drivers, the file handle seems to be closed when an attempt is made to unload the driver. NOT when the driver can be unloaded. For example, even though there are references to the device and driver objects, the file handle will still be closed.

    You can now delete or overwrite the driver file, not knowing that the file is still mapped. New data or zeros will be brought in when a pageable code will need to be paged in. BUGCHECK!

  4. cheong00 says:

    Talking about filesystem, I just know that starting in Windows 10, version 1607, you can opt-in to remove the MAX_PATH limitation via a registry key change or App.manifest setting.

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

    I wonder when this will be applied to the server SKUs, and which server version will get it.

    1. Rick C says:

      Group Policy editor says “at least Windows Server 2016”.

      1. cheong00 says:

        Nice. Thanks.

        So some legacy software that has directory structure levels grew ridiculously deep could be benefited from an upgrade.

    2. MarcK4096 says:

      Nice! I hope File Explorer opts in to the new behavior.

Comments are closed.

Skip to main content