When modifying files on a VMware workstation shared folder (i.e. \\vmware-host\... using vmhgfs.sys) via memory mapped I/O (e.g. CreateFileMapping/MapViewOfFile) the updated content is lost if the range is not forced out using FlushViewOfFile before the view is unmapped.
This explicit flush should not be needed per UnmapViewOfFile function (Windows). The content should get written anyway when the page's share count hits 0 (the page has been unmapped from all processes that were sharing it), and it works as expected on local volumes like C: and also on network volumes over SMB.
MapViewOfFile.cpp (attached) is a simple test app which demonstrates the bug. When run, it writes "Hello, World!" to the file hello.txt in the current working directory. If you run it in a folder on C:, or on a network share, this works fine. If copy it into a folder on \\vmware-host\Shared Folders and run it, it fails; the file is created with the correct size but it just contains '\0' bytes. If you uncomment the call to FlushViewOfFile, the file will show the correct content. But (obviously) one can't easily patch arbitrary windows applications to do extra flushing that the API doesn't require, so this isn't a solution, just a workaround.
This test app is of course very synthetic, but I originally encountered it with real programs. Specifically, I was trying to set up some older Visual Studio versions inside VMware. I wanted to use Unity mode to have the IDE still appear in my normal start menu as if it was installed in the host, while isolating isolate the actual compiler installation that things like COM registration could be managed using snapshots and rollback. To make this feel even more transparent, I created symlinks to redirect paths in the guest's C: drive to their corresponding \\vmware-host\Shared Folders\... equivalent, so the same paths referred to the same files in both the host and guest (e.g. mklink /D C:\projects \\vmware-host\Shared Folders\projects, which is sharing the hosts's C:\projects). When I did this, everything worked great except the visual studio link.exe, which failed with strange messages that look like uninitialized memory. I finally tracked this down to the .exp and .lib files (which are written using memory mapped I/O) being full of 0s instead of their real content, which presumably caused some buffer-handling mishap when link.exe read them back in. I then created MapViewOfFile so I could give you a far-simpler testcase for the vmhgfs.sys bug 🙂
VMware Workstation 12.5.4 build 5192485
Host is Windows 7 Enterprise, 64-bit Service Pack 1 (Build 7601)
Guest is Windows 7 Professional, 64-bit Service Pack 1
VMware Tools 10.1.5 build 5055693
Thanks for reporting this and providing a test applicaion. Although I am not sure why our internal tests don't catch this.
I thought we had a very similar one which I will also check out now and augment it too.
I am on it and will get this issue addressed as soon as I can.
Thanks for looking into it. I figured I had little chance of getting a vague "visual studio link.exe gives a weird error message" report fixed, but hoped that if I could isolate it into a nice standalone test-case there might have a chance 🙂