Problems with Shared Folders and Visual Studio 2008

[SoMoS]

Hello,

I've just setup a virtual machine to work with some big projects in C++ with visual studio 2008. To make the code available at several virtual machines I created a shared folder at the host with the code.

The fact is that Visual Studio has problems working with the shared folder as i get "file in use" so often. Retrying the operation solves always the problem. Thant problem does not happens if the code is local or in a Network Share.

Any hints?

[DavidWoodward]

You're not alone.  Same problem here with VMware Player 3.1.4 build-385536 and Visual Studio 2010.

However, I don't think it's just Visual Studio.  I've also noticed that I have trouble accessing or renaming large directory structures (ie. a folder with hunderds of files under several sub folders) that exist under a shared folder. In general, if I use the command line to access/rename the folder before explorer ever sees it then I'll be ok.  But as soon as any GUI sees the folder and tries to enumerate the contents I'm stuck.

It's as if some buffer keeping a catalog of files that need to be released by the shared folders service is overflowing and hence the lock on the file is never released.

I often can't rename the folder until I disable and re-enable the shared folders on that VM.  Oddly enough I can generally delete the folder even when I can't rename it.

I'd really appreciate an answer on this.

Thanks,

David Woodward

[WoodyZ]

In spite of the resent gains over the last year or two with the VMware Shared Folders feature (HGFS) nonetheless it still may some issues and IIRC Visual Studio is one of the Applications that has had its share of issue with HGFS in the past so my recommendation it to not use the VMware Shared Folders feature if it is being problematic and instead use normal industry standard SMB/CIFS File Sharing.

[DavidWoodward]

I'd love to (SMB/CIFS is much faster), but due to security concerns I'd like to restrict my VMs to a single folder on my host system rather than actually having them on the same network.

[WoodyZ]

Granted the default smb.conf under OS X is not as secure as it could be however there are lots of ways and layers to increase security and it can be edited and configured to be extremely secure and as a matter of fact when I'm not on trusted networks, like if at the library or such, I have it configured to only allow my Virtual Machines to access the OS X Shares so not only would something have to get through my Firewalls and Filesystem ACLs it will also have to be on VMnet1 which is the Host Only Network and not accessible from outside the Host anyway.

Edit: Sorry I just realized that you're using VMware Player and I'm on a Mac using VMware Fusion sorry however there are measures you can take on a Windows Host or Linux Host as well.

Message was edited by: WoodyZ

[DavidWoodward]

Thanks for the suggestion, but I'm in a bit of an odd scenario here where having the guest system and the host system on the same network (virtual/vmnet1 or otherwise) is just not an option.

I understand that I can lock down the host system's firewall and services to limit its accessibility from the guest system, but in my scenario the restrictions are imposed by policy, not technical capability.  We don't want the guest OS to have any kind of communication with the host OS.  I'm not even certain that shared folders are allowed, but since the feature isn't working anyway there's no point in trying to get it approved in my environment.

[WoodyZ]

but in my scenario the restrictions are imposed by policy, not technical capability.

That's understandable as policy rules in managed scenarios.

[steve_goddard]

File handle closing has been fixed with Visual Studio 2008 with the Workstation 8.0/Fusion 4.0 betas.

If you can try this version I hope you will see the improvements.

If there are still issues please continue to report.

Thanks.
Steve

[WoodyZ]

Steve I'm not the one using Visual Studio 2008 in this thread although I have Visual Studio 2010 and haven't tried it with VMware Shared Folders in VMware Fusion 3.x or the current Beta.  It's just easier for me to use what has always worked before there was HGFS and because HGFS had so many problems for so many years and still does have a few I hope you can understand why it is one feature that with the exception to test as necessary to provide support for users in the forums I just will never use it.  I just never had any issues with SMB/CIFS Shares like with HGFS and yes you have made tremendous improvements compared to what it was going back a couple years however because of how long it took VMware to make it a viable feature I'm just more comfortable with using SMB/CIFS Shares.

Keep up the good work for the other users!

[steve_goddard]

Sorry for the confusion, my response was intended as a general reply to the discussion as a whole, not really a direct response only to yourself.

Basically, to let everyone interested in this issue to know that some issues wrt Visual Studio have been addressed to improve that applications user experience with HGFS shared folders.

Thanks for replying. I hope that the latest versions will enable users to be productive in their daily activities, and that they will continue to respond when issues occur.

Steve

[DavidWoodward]

Steve Goddard wrote:

File handle closing has been fixed with Visual Studio 2008 with the Workstation 8.0/Fusion 4.0 betas.

Thanks for the update Steve.  I don't have a license for Workstation at this time, but I'll look forward to the day when the changes finally get rolled into a VMware Player release.

[WoodyZ]

David, While Steve didn't explicitly say VMware Player it is included in VMware Workstation Beta so you might what to join the VMware Workstation Beta and give it a try.  I'm pretty sure whatever HGFS bugs get fixed in VMware Workstation 8 will translate to VMware Player 4 as well.

[steve_goddard]

Thanks for the replies.

Yes, the fixes that go into Workstation, will be there for the corresponding release of player too. There should not be any difference as far as the Shared Folders feature goes. Sorry for not being explicit about that.

Steve

[DavidWoodward]

WoodyZ wrote:

... you might what to join the VMware Workstation Beta and give it a try.

How do I join the beta program?

[WoodyZ]

http://communities.vmware.com/community/beta/betainterest

[DavidWoodward]

Hmmm...  "Participation in many of our beta programs is by invitation only; ..."

Oh well, I submitted a request anyway (twice I think - oops).  We'll see.

Thanks for the link.

[steve_goddard]

HI David,

I just fixed a problem with Visual Studio and 64 bit Windows VMs. I don't see anything mentioned about whether you are running a 32 or 64 bit VM, but if you are running a 64 bit, you may see PATH NOT FOUND errors incorrectly returned when files should be created successfully.

This was due to an error parsing the share component of the path incorrectly i.e. not case insensitively.

Steve

[JDlugosz]

I'm also having problems, using Visual Studio 2005 in a VM (so I didn't have to install an old VS on my machine).  I don't want to use regular network sharing because the files I'm accessing are encrypted on NTFS, and only the host's user account can access them.  With VM folder sharing, the credentials are that of the user on the host machine running the VMWare Workstation.

It's difficult to use this, with a build giving errors due to files "in use".

I've renewed my interest in being a beta tester.  Can you maybe pass this along to someone so I can indeed use it, soon?  Is anyone testing the new version with this kind of situation?  It might be good for you to add it!

—John

[WoodyZ]

I've renewed my interest in being a beta tester.  Can you maybe pass this along to someone so I can indeed use it, soon?

If you go to the VMware Workstation forums main page it has a form to "Participate in a VMware Fusion or Workstation Beta" so fill it out.

[JDlugosz]

I did exactly that, before writing the post. I've done so before, and it never came to

anything.

That's why I asked you to put a good word in, as well.

—John