I/O Exception in Fusion v4 reading from Shared Folders on WinXP Pro Guest

[nathanwiebe]

I am having issues with Shared Folders on a WinXP Pro guest.  When I try to read a decent size collection of files (e.g. copying/reading a folder full of small files from the shared folder to the guest's HD) I get I/O errors.  ("Cannot copy xxxx: The I/O operation has been aborted because of either a thread exit or an application request").  For example, there are several SVN folders that can't get through an update from the guest OS without throwing this exception, necessitating an SVN Cleanup from the host OS.

It works fine if I access the host OS's own samba share, and it works fine on my Win 2000 Pro VM.  It's like there's a bug in VMWare's ?samba? server that it uses for the Shared Folders that only affects WinXP Pro.

I have no idea if this is a v4 bug or more generic, but this is the first I've noticed it.

Any thoughts or similar experiences?

Details:

MacBook Pro, Fusion 4, WinXP Pro VM

[Levi9000]

I also have the same problem. As soon as I installed VM Fusion 4 it started throwing IO Exceptions and IO Errors when trying to access my shared folder. It doesn't even have to be a large number of files, it just happens randomly. It's so bad that I am going to revert to VM Fusion 3. I have tried everything else, including "downgrading" my VM to be VM Fusion 3 compatible with no luck. I have it configured such that the shared folder is My Documents, so I really can't just stop using the shared folder during normal use.

I use my VM every day and never had the problem until the day in installed Fusion 4, so it must be a bug in Fusion 4.

Details: MacBook Pro 2011, OSX Lion, Fusion 4, Windows 7 64-bit

[nathanwiebe]

I'm sure we are seeing the same bug.  It is random for me too, but reading a large collection of files is where it's guaranteed to fail.  I think the bug is in the SMB server in VMWare Fusion that hosts the shares.  My workaround was to create an SMB share on the Mac OS itself, and map that drive instead.  I have tested this extensively and the issue is definitely no longer there (on the Mac OS SMB).

Also of note is that my Win2000 Pro VM and Ubuntu VM don't experience this bug, but my WinXP Pro does.

[VirtualHorse]

Signed up to say I'm getting the same error on two separate virtual machines running under 10.7.1 and Fusion 4. The first machine runs a 32-bit version of WinXP. The second runs Windows 7 (64-bit) from my Bootcamp partition. I had no problems with either running Fusion 3.

For me, the problem manifests itself when I try to create an ISO image using ImgBurn. The files (and the ISO output) are from a VMWare shared folder. Attempting to write the ISO throws up repeated "cannot write: the i/o operation has been aborted because of either a thread exit or an application request" errors on the WinXP guest (which I can click through). But the Windows 7 guest locks up completely:-(

Strangely enough, I can burn discs from files on Shared Folders. It seems that attempting to write to the folder sends it haywire.

[Levi9000]

Just wanted to follow up and say that I did solve the problem by downgrading back to VM Fusion 3, however the problem did not go away until I uninstalled the vm ware tools in the guest OS and reinstalled the tools for v3. So that means the problem most likely exists in the vmware tools themselves, in the guest OS.

I guess I will wait for the next update before trying again.

[RTMgermany]

Same issue here. I'm using Visual Studio with a project that's on a shared folder. V3 worked without problems - V4 is not usable...

[VirtualHorse]

Just wanted to add that I followed nathanwiebe's suggestion and set up an SMB share through OS X's built-in file sharing (and turned off Sharing in the Fusion guest) and it worked perfectly, so it's definitely a bug in the new VMWare Tools' implementation of SMB/sharing. Downgrading to Fusion 3 (or switiching to Parallels) seems to be the best solution.

This is a pretty major bug, I think, and easily reproducible, and I'd like to think the Fusion engineers could patch it quickly once they're made aware of it. But do we need to submit this in an official bug report? Do VMWare support staff follow these forums?

[steve_goddard]

Hi All,

I am a developer for the VMware Shared Folders feature and I think I have a fix for this issue.

I am going to try and reproduce it myself and retest my fix to be sure. So I hope this won't be too long in making it out into a VMware tools release.

I will update again here when I have confirmation of the fix.

Thanks for bringing this to our attention.

[steve_goddard]

One thing you can check and try which might help is that if your VM has more than one processor try running it with only one and see if this reduces the frequency of the issue. If you see it in VMs with only one processor too then let me know too.

Thanks.

Steve

[synchromesh]

I can also confirm that switching to using the OS X SMB shares & Windows SMB client works around the problem. My Windows XP Pro guest has 2 CPUs and the problem started immediately after I "upgraded" to 4.0. Doesn't say much for VMware's regression testing procedures, especially for a paid upgrade.

[Levi9000]

Thanks for the update Steve. Glad to hear the issue has been noticed by the dev team.

Unfortunately I can't afford to reinstall Fusion 4 and do more testing at this time, but I can confirm that I was using 4 processor cores in the VM when I encountered this problem.

I hope someone else still has Fusion 4 installed and can test this theory.

Levi

[nathanwiebe]

Here are the results of my testing:

-I put a folder on the shared desktop (836 files, 60MB total).

-Duplicating the folder, 10 out of 10 tries failed within the first 20% of the copy on a 2 core VM.

-10 out of 10 tries succeeded on the same VM running on 1 core.

Also, if any of this matters: Windows XP Pro VM with 1024MB RAM, OS X 10.6.8 on a 4-core 8GB 2011 MacBook Pro, VMWare Fusion 4.0.1 (474597)

Thanks a lot for the heads up.  I'm looking forward to the patch!

[steve_goddard]

Hey thanks for testing it out.

That really helps confirm what I have fixed is your problem too.

I have managed to replicate this in house now too with  a mulitprocessor VM.

[VirtualHorse]

Thanks, Steve. It's really good to know you guys are on top of this. I've downgraded to Fusion 3 until this is fixed.

I can also confirm that the two virtual machines I had problems with were set up to use multiple cores: 2 for the WinXP machine and 4 for the Win 7 machine.

[Eli85]

Hello, I just wanted to report that the issue described above also occurs with Workstation 8 for Linux and WinXP Pro Guest.

I didn't try yet switching to 1 vCPU VM to check if that helps.

Details: Ubuntu 10.10 x64, kernel 2.6.35-30-generic, Workstation 8, WinXP Pro VM

[steve_goddard]

The issue is in the windows client file system driver and has been fixed internally to VMware. The fix will hopefully make it into the next set of VMware tools releases. So keep updating when you see newer versions released. That goes for workstation and fusion products.  Thanks

[Eli85]

Thank you!

[frogworth]

I'm glad this has been noted and fixed internally, as it's a problem for me too. When I upgraded to Fusion 4 I noticed files being strangely truncated when saved to the Z: drive shares, when they wouldn't be if saved to the same folders shared via smb network shares.

Because of this I've had to downgrade to 3.1.3, so I'm wondering how we'll be notified that the fixed version of VMware Tools is available if we're running the older version of Fusion? I'd want to find out, as it would enable me to upgrade!

My other workaround was to connect to the shared folders as smb shares from the host computer, via the IP address in the NAT network it shared with the guest. The file truncations don't occur under this scenario, but the trouble is, every few times I sleep the computer or reset the VMware network, WinXP would somehow not manage to reconnect to the host computer at 192.168.56.2 - and the only solution would be a reboot.

This happened a lot more frequently in Fusion 4 than in Fusion 3, making it too unreliable to use.

It will presumably still be a problem, but the fix for shared folders will essentially solve the problem - although I still need the NAT network in order to map certain ports to Windows programs in the guest. That's for another thread though!

[steve_goddard]

Hi there,

Your question about notification of specific issue fixes is a good one. The general policy of just being notified every time there is a newer version of the current release does not cover the granularity you are looking for.

Currently, the policy also extends to prevent me from being able to mention any dates of any upcoming releases at all. So all I can tell you is when the bug fix is included in an upcoming next release, but not say when you will see it.

I will pass on your information and question to the relevant people and I hope there maybe some more better ways of users getting notifications of specific fixes when they go on general release.

All I can say for now is that, I will update here (and possibly send you a private message too) when I see that fix be incorporated into a new tools release, and again, when it is definitely released.

Sorry that there is not a better answer as far as I am aware currently.

Steve

[frogworth]

Hi Steve,

Thanks - I'm happy to watch this thread, and if you send me (us?) a private message then even better, but that'll do for now.

Yes, it'd be great to sign up for notifications, but at least this way I know I won't miss out.