VMWare Workstation 8 on Windows Host: Please fix stubborn handles in vmware-vmx.exe

[quiettime]

Hello, I have complained about this before and here I go again. VMWare has long had a stubborn handle problem with shared folders. For example if you share a folder with a guest and then copy an exe from that folder in the guest VMWare may still maintain an open handle to the exe on the host. Even if you log out of the account on the guest, or reboot the guest, the handle remains open by vmware-vmx.

This plays out for me in the following way. I develop on the host in Visual Studio, and I share the output location with a guest. If I copy the file on the guest it remains open in the host. So when I make whatever change I need to make and then attempt to rebuild on the host I cannot because of the open handle. The workaround for this is currently to copy the exe *in the host* and then make it available to the guest, which is less than ideal, and must be done once per change (ie a.exe, a1.exe a2.exe a3.exe). Alternatively I could pause and resume the guest but that takes longer.

Observed in 8.0.0 build-471780 and of course 7.x versions.

That is terribly annoying and this is a petition to fix it. If you want this fixed reply with +1.

Thanks

[satya1]

can you share your application ?

Yours,

Satya

[quiettime]

It's not specific to any application, it's just the way their shared folders work. I'm having more problems with shared folders now that I've upgraded to WS8

[steve_goddard]

Hi,

I am the developer for this feature and this is a known issue and I want to take a little time to explain it and why this has not been fixed.

This issue is due to the way the windows OS memory manager works with the underlying file systems, and is not down to any particular aspect of the VMware shared folder or any application in particular.

When an application like Explorer copies an executable file or an executable file is run the windows memory manager will hold onto to a reference to that open file long after the application has closed any open handles or the application has terminated. This is to optimise any second attempts to run the same binary so that it can be launched much more rapidly if some part or all of the image is already in loaded memory.

The downside here is if on a remote or in this case the host side wants to access the same file these open references cause the host application to fail to access the file. In this case the VS and compilation tools trying to rebuild the binary.

The way this is normally handled is by use of remote locking the Windows implementation of this is called Oplocks. These allow the VM client file system to lock the file on the server when an open reference is held. The host application when trying to access the file will be temporarily blocked while the client has the lock but the client is notified to break the lock and close the reference. Once that is done the original request for the open on the file from the host application proceeds successfully and it continues on. This is the only way the remote client can know that someone else wants to access the remote file from the host side.

Currently this remote locking feature is on our radar to address this exact issue and a couple of others. It is a large and complicated feature to implement and we have to get it supported on Windows hosts, Linux hosts and OS X hosts, plus the Windows client. The last of these host  platforms, OS X, is the most difficult. We are going to try to get this done for the next major release but we do have very limited resources right now, just me in fact,  so I have lots of stuff to get to but I really would like to get this feature implemented.

Also another quick temporary workaround to flushing out the the open references would be to go to the UI and disable the shared folders feature and then immediately enable it again. Not the most ideal way but it will allow you to carry on and it should be reasonably quick to do.

I hope this helps and I appreciate your patience and understanding while we try to get these issues addressed.

[SiHuWa]

Thank you Steve for your explanation.

You mentioned the following:

Also another quick temporary workaround to flushing out the the open references would be to go to the UI and disable the shared folders feature and then immediately enable it again. Not the most ideal way but it will allow you to carry on and it should be reasonably quick to do.

While it is great that we have a workaround, it is a fairly clumsy one which requires one to navigate through dropdowns and tabbed dialog windows to firstly disable and then re-enable to workaround this issue.

What are the chances of VMware including a simple keyboard shortcut that enables/disables "Folder Sharing" until a more permanent solution is developed to resolve the underlying issue here?  This would make alot of users very happy as it would reduce alot of the headache that this issue incurrs.  I say this as someone who uses VMware Workstation for his software development environments and who has to "reset" the "Folder Sharing" many, many times a day.

Cheers!

[steve_goddard]

I'll file a request and we can see if this can be done. I will let you know when any response is given. (another group is responsible for the UI stuff like this.)

[nihique]

+1

I have the same problem, this is terrible issue and makes using shared folder pain!

[TXuser]

Yes, I use shared folders heavily in WS 7.15 and the only issue, and I really mean the only issue that I have encountered with shared folders is the one in this thread.

As a workaround, I use Unlocker 1.91 and it works quite well. In the host you can right click the file and use Unlocker to unlock the file(s). If you're having the same issue with the same file being locked, create a script on the host that will unlock the file on the host in a batch file.

http://www.emptyloop.com/unlocker/ Run Unlocker.exe with /h or /? from a DOS prompt to see the command line options.

I hope this helps until VMware comes up with a solution.

Hawkeye

[BobAgi]

Is this issue with the Windows native shared folders over the network or is it with the VMWare built-in shared folders?

If the latter, then why not use regular Windows shared (samba) folders instead?

[TXuser]

BobAgi,

To answer your question, first the shared folder is located on a different drive of the VM's. I have only one shared folder with multiple folders within it. Each VM is mapped to the shared folder using the same letter.

Yes, I could achieve all the items listed below with a network share but using shared folders has worked very well for me. One advantage of using shared folders, they are faster than network shares.

1. I have a couple of VM's that I do development in. These are setup as bridged but most of the time, they are disconnected. Usually they connect, only  to get updates. Yes, I could have setup them up as NAT but I prefer the bridged mode.

2. The source is in the shared folders and I compile from a VM. The output is saved in the shared folders and I can quickly test from other VM's or the host quickly with shortcuts.

3. You can place software, like Sysinternals Utilities in a sub shared folder with a shortcuts and all the VM's have access with one location. Very easy to update one location for multiple VM's.

4. If restoring from a snapshot, you don't have to worry about, did I copy my data to a safe place. The shared folders are not affected by snapshots just as network shares would not be affected.

5. Keep the data safe. I have routines to back up the entire shared folder or certain folders under the main shared folder. Yes, there are times, I copy the whole VM as a backup as well.

6. Even though, I have not tried these, other possibilities include moving MY Documents, page file or anything else you want on a separate drive.

On the forum, I have read about a lot of issues using shared folders. Like I stated earlier, the only issue that I have experienced is the file locking issue. To remedy that, using, Unlocker, it is a quick workaround when needed.

TXuser

[BobAgi]

I have only once (a long time ago) tried the VMware shared folders, but decided not to continue.

Likewise in  the old VirtualPC days (from 2004 to about 2007) I at first used their "shared folder" feature, which was much simpler to set up and use by the way. But then there crept up some very serious issues with these folders, it seems like they were designed for a small folder depth and small number of files only. When some limits were exceeded they stopped working. So I abandoned these.

After that I have always successfully used network shared folders, i.e. I have a folder on my host machine that is accessed from the guest via Windows drive mapping.

If I want to protect the guest from the brutal Internet then I set the network interface to "host only", which effectively limits the scope of the networking on the guest to the host itself. Works fine for me. I have guests of different kind and some have no AV software loaded so they are host-only guests.

With this setup I guess you would achieve all of your goals concerning data protection and guest updates etc.

I have no idea if there still are file locking issues in this case, but I think not because if they were still present then server side data storage in companies would not work.

Security of your data sources...

Well if you don't already use some version control system I very much recommend you to seriously look for one to use. It gives you a lot of extra functions over just using file backup schemes. And there are open source systems available for free or a low cost maintenance contract.

I have been very happy in two different companies with CVS for 10-11 years now and I use it on my home projects as well. Never lost any sources anytime after starting to use CVS.

But CVS is no longer the hot item it was 6-7 years ago, nowadays people look at Subversion and Git. I don't since CVS serves me good enough.

Just some ideas,

Bo B

[vearom]

For me the problem is larger than just improper handling of .exe files.

When copying files (any type) from/to Shared folders, it consumes Windows(host) handles until Windows get out of handles (XP is having strong limitation and it gets out of handles much earlier than Win7).

VMware player 4.0.2 build-591240, Host Windows XP professional 5.1.260 SP3, Guest Linux Mint 12

VMware player 4.0.2 build-591240, Host Windows 7 Professional, 32-bit 6.1.7601, Service Pack 1, Guest Ubuntu 11.10

[emusic]

Steve's explanation looks reasonably. But I used Workstation 6.0.x with XP/Vista/Win7 guests for years and never saw this problem. As I upgraded my Workstation to 8.0.3, keeping all machines unchanged, I immediately started to see it.

So VMware version/code is definitely related to the problem.

[emusic]

I found if files are copied by FAR Manager 2.0 and 1.75 with option "Use system copy routine" unchecked, vmware-vmx process does not leave these files opened, regardless of that are files executable or not. But I use some automation with command files so interactive copying is not always suitable. Investigating further, I found that files opened with FILE_FLAG_NO_BUFFERING are not locked. So I wrote a simple utility that copies a file opening both source and destination with this flag. I could publish it if somebody wants.

[evgenios]

I would be grateful if you send me a link to the utility you wrote.

[emusic]

copywobuf utility