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
