I may have discovered a bug in VMware's Shared Folder implementation in VMware Fusion 4 on OS X Lion (10.7.1). When using the Microsoft manifest tool (mt.exe) to add some metadata to an executable I receive the error code 1392. The mt.exe is on the C: drive inside the VM, but the two files it is operating on are on my Z: drive (VMware Shared Folders). This bug did not occur in VMware Fusion 3 with Windows XP x86 as the guest. But now I'm using VMware Fusion 4 with Windows 7 x86_64 as the guest (with UAC disabled).
If I turn on Samba on my host and map my host's folder from the Windows guest the command works. If I copy the files in question to the guest's local drive the command works. The only time the command fails with error 1392 is when I issue said command against files on the VMware Shared Folders.
This is *really* annoying because although my source code is versioned with git, I like it all stored on my OS X filesystem since I use a separate backup solution on the host to make sure I get good backups each night. The Samba solution I mentioned isn't really a solutions since my company's VPN no longer allows split tunnel access. When I'm connected to the VPN inside the Windows guest all my routes belong to Cisco AnyConnect (aka I can't access my host network to map a Samba share).