Remember that virtual hardware is different from physical hardware, so it's quite possible (and even likely) that the virtual machine has a (virtual) floppy drive and can be using a (virtual) optical drive even though the Mac's drive is not in use.

Ok just updated to 2.0.5 again. Removed Tools and installed them again. Works

So it's an update problem Thx

Hi there,

Sorry for the delay in responding, I am in the middle of urgent changes for the next major Fusion release.
So the file system for Shared Folders is working and drive mappings are accessible and the drive mappings
you are showing in your image of the dialog box is from which application exactly? Is the application built on top of MacFuse?

On Windows (BTW which version, is it XP?) explorer does think the drives for VMware Shared Folders are all connected? It looks
that way from the picutre of the icon , can you also do a "net use" from a command prompt too? I hope the status field of the output
listing is probably blank for the Shared Folders mappings. Is that the case?

I need to know a little more about the application. My guess is that for some reason that it thinks the drives associated with the
VMware Shared Folders are not connected and so does not list them. But you state that this previously worked with version 2.0.4 Fusion
is my understanding correct?

Steve

In the first place they are not called a "unit", they are called a "drive" and as I already explained in an earlier post the reason your seeing the Floppy A: Drive show in Windows Explorer and Device Manager is because regardless of whether or not one is assigned under the target Virtual Machine's Settings because the Virtual Machine's BIOS has the floppy defined by default and that's why it appears in both Windows Explorer and Device Manager.

The D: Drive is the CD/DVD and it has the VMware Tools ISO Image loaded in the picture and normally VMware Tools gets ejected after the install if all goes well so if you've already installed VMware Tools you can select Cancel VMware Tools Installation from the Virtual Machine menu and it should remove it from the D: Drive.

Sorry for the delay, the website was down and then I had a multitude of stuff to get done.

However, this is generally a bug on our part and I am going to file it as such. It looks as though we are missing some missing IOCTL support in our driver
to handle connection information. Unfortunately, the reason that we are missing these is that they are undocumented. Sigh.
I will try and get this uncovered and so will then test them out and see if they definitely fix this issue. I think it it makes sense that it will, but would like to
be sure. I can easily reproduce this myself too.

Thanks.
Steve

Hi there
I am not sure what you are asking exactly.

This is a bug, which requires me to add support for undocumented requests to our network file system driver.
First though, I have to find out how these are used, what the arguments and replies
should be, not easy, when it is not documented. Then, I have to prove this is the required fix and the problem gis addressed.

Then we have to issue a fix in a release, which will probably be in a point release after the next Fusion major release.
It is probably too late for the major Fusion release at this point, but I will try to get it in if I can find out the undocumented details in time.

However, this is not likely to be fixed in a release immediately. It will be fixed though, and I can let you know when the bug
is fixed internally and to watch out for the next update that will contain it.

Currently, we have other more major bugs ahead of this one to be addressed but it will be fixed.
As for a workaround, I am not sure as what to suggest other than use WNET Windows APIs instead of the one you are currently
using. These go through a different code path. See http://msdn.microsoft.com/en-us/library/aa385478(VS.85).aspx.

Steve

trying to use the example that worked here, I tried to uninstall the VMWare Tools from my image, but I get the error attached, which says there is an invalid drive. The drive, Y:, was the drive that was mapped to the VMWare Shared Folders - which of course is the root of the issue.

When I can work on this more later, I may attempt to revert to an older snapshot and then remove and upgrade the tools from there.

above, user h0lzi stated they got things working by simply uninstalling the VMWare tools in the guest and installing them from scratch. Has that been proven not to work? I've been pulled away on other things all morning, but want to try this out. Are you saying that is a non-starter?