Shared Folders Still Not Fixed in 2.0.2...

Dr_Gary · ‎02-11-2009

It appears that the one bug fix that I have been waiting patiently for has still not been addressed in release 2.0.2. Very disappointing.

The shared/mirrored folder SMB "lag"...at least with a Windows XP guest remains very apparent...I actually see no improvement at all. This causes Windows applications attempting to use a shared folder reference to experience write failures, etc. Totally unacceptable.

So...I am still unable to use this feature for my clients running Fusion...very, very disappointing...there were several threads on this board from VMWare folks that indicated this problem had been solved and was simply being QA'd for the next release. What happened?

Here is the Link:

http://communities.vmware.com/message/1130487#1130487

I guess Steve was misinformed...

WoodyZ · ‎02-12-2009

I updated my original post with the reg export commands. I missed the first key you wanted sorry. Also this was really to make it easier for the user you wanted the information from.

The main reason I prefer an exported key via the command line is if a User doesn't know what they're doing they should not run regedit even to export a key as it to easy for to screw something up and the command line in this case is safer. While you may get a bit more info in this case at least by having it exported in this manner you've kept a unknowable user out of the registry and it safe and there is no doubt as to what the information is when you get it.

steve_goddard · ‎02-12-2009

Thanks, they are handy to script which will make things easier, as next time I will ask someone to run the script instead.

Yes, a good idea to avoid the delving through the registry for those who are not sure.

Zach seemed comfortable and got the data I needed.

Thanks. Steve

steve_goddard · ‎02-12-2009

The file fmhgfs.dll exists at C:\WINDOWS\SysWOW64\

This should be vmhgfs.dll not fmhgfs.dll which I assume was just a typo, and if so, everything looks to be in order.

So I will see if I can find a reproducible case in house. I will update again soon.

Thanks very much for retrieving the information.

Steve

Thanks. Steve

RcktMan77 · ‎02-12-2009

Steve,

Your assumption is correct. The file is vmhgfs.dll at C:
WINDOWS

\SysWOW64\

My clumsy fingers got in the way.

Zach

Dr_Gary · ‎02-13-2009

Steve,

Here is what I have been able to gather on my testing with Avast 4.8 Home with respect to the shared folders "lag" issue:

1) If Avast is uninstalled or you simply select "Disable On-Access Protection"...the symptom completely disappears

2) When the symptom does occur...and it is intermittent, as you stated, there is a small but noticeable "blip" of network activity

3) The cursor remains an hourglass and there is no further activity until this "blip" of network activity ceases...then Windows Explorer continues

Normally, while Exploring a Fusion shared folder...there is no perceivable network activity...like there is when you browse a "real" network share...that's why the "blip" of network activity caught my eye. It seems as if Avast is creating some type of network request when accessing certain folders...and is then preventing Windows Explorer from continuing until the request is answered or times-out.

Thanks for you assistance on this.

Gary

steve_goddard · ‎02-13-2009

Okay I know why we are seeing the glitches in the when accesses to the shared folders occur with Avast is present.

It is really our fault and a bug that has been on my radar for a while. However, it just has not knowling caused issues like this until now.

So I will raise the priority of the bug and we will address it for the upcoming releases.

The problem if you would like more details, is how we pass names resolved from the user mode component of the shared folders file system.

It should use more information than it does when creating the links for the drive mappings to server and share name. This causes information

to be missing when Avast tries to do it's internal opens on files to scan them ahead of the calling application. This causes the Microsoft network

component to try to resolve the name to see which network file system should get the request. Unfortunately, we fail it and so does Microsoft's SMB

file system, only SMB file system blocks on a 5 second timer before giving up.

When I try a regular straight UNC path in the Explorer address bar:
.host\Shared Folders

Then drill down the directories this way I don't see the glitches. This matches my hypothesis above and what I would expect.

Can you confirm this behavior too? (That is with drive letters mapped you see delays, but with UNC path like above, you don't.)

Thanks.

Thanks. Steve

RcktMan77 · ‎02-13-2009

Steve,

I've seen both your posts in this and the other thread relating to the shared folders feature. Just to let you know, I get the same network error message as before when I enter
.host\Shared Folders in the Explorer address bar. Namely, "Windows cannot access
.host\Shared Folders". I'm not sure whether your post was intended as a response which included the trouble I mentioned yesterday, or just those who have Avast installed on their VMs. Either way, entering the network location in the Explorer address bar doesn't work in my situation.

Zach

steve_goddard · ‎02-13-2009

Hey Zach,

This might be the same issue, and mean that you have done the test that I am asking in the other thread. Your findings are what I would expect.

To address that I would be grateful if someone could run the file spy utility and save the file IO log and upload it. If that is easy enough to do?

Run the filespy utility and on the menu Volumes, select Attach to device by name...

and type \Device\HGFS

Enable capture of events n the Options menu.

Try and access the UNC network path as you previously did. Save log and upload here.

Can you try that for me?

Attached the zip.

Steve

Thanks. Steve

RcktMan77 · ‎02-13-2009

Steve,

I'm working on that. Just one question, as I've run into an issue. Is

HGFS an abbreviation for something? I ask because using \Device\HGFS

prompts an error message that reads:

Failed to start logging device "\Device\HGFS". The system cannot find

the file specified.

Sorry for my ignorance if this is a commonly used acronym for which

I'm unaware.

Zach

RcktMan77 · ‎02-13-2009

Okay, Host Guest File System...but why am I getting this message that \Device\HGFS isn't found? Perhaps it has to do with the vmhgfs files being stored in \WINDOWS\System32 and attempting to run 64-bit Vista and Filespy?

Dr_Gary · ‎02-13-2009

Steve,

You are correct. I repeated my testing using the UNC instead of the mapped drive...and the symptom does not occur.

Is there any possible workaround that may allow the drive letter to be used...or is the UNC the only way until the bug is fixed?

Thanks again for your help in this matter....

Gary

steve_goddard · ‎02-13-2009

That surprises me, oh, wait, you are using Vista right? In which case, due to platform differences from earlier versions, you

should attach to \Device\MUP

which is on the Volumes menu explicitly. Select that such that the menu shows a tick by its name.

Then you should be good to go.

Sorry for the mistake, XP and 2k3 what I originally told you would be correct but not for Vista, Win7 etc.

Thanks

Steve

PS Good deduction on the name!

Thanks. Steve

WoodyZ · ‎02-13-2009

Is there any possible workaround that may allow the drive letter to be used...or is the UNC the only way until the bug is fixed?

Based on Steve's description of the bug I say no to the drive letter and UNC will be the way to go until the bug is fixed.

steve_goddard · ‎02-13-2009

Gary

There is a way! Gulp, but may not be workable for you.

Basically, you have to disconnect from the network in your VM. That way, the Microsoft SMB network file system will not cause the 5 second delay.

If you are okay running your VM off the general network and can just use VMware shared folders then this can work for you.

Otherwise, no real way out.

Hope this helps.

Steve

Thanks. Steve

RcktMan77 · ‎02-13-2009

Okay, Steve--See attached output.

Zach

WoodyZ · ‎02-13-2009

There is a way! Gulp, but may not be workable for you.
Basically, you have to disconnect from the network in your VM. That way, the Microsoft SMB network file system will not cause the 5 second delay.

Now that you said this I just realized that all the testing I have done with VMware Shared Folders in 2.0.2 that my Network has been disconnected (and normally it's not) however upon connecting I and now experiencing the delay. That's it I'm switching to Parallels 4!

admin · ‎02-13-2009

I see you've figured out what HGFS stands for already, but you may be interested in

Dr_Gary · ‎02-14-2009

Steve,

Thanks for the update. Unfortunately, working with the network disabled is not going to be a viable option for me.

So...I guess I will be waiting for the next bug fix release...I sure hope this is fixed at that time.

Once again, thanks for all your time and investigation on this...

Gary

steve_goddard · ‎02-17-2009

Gary,

I did miss off one option n my haste to make a flight on Friday night, and that was to use a different anti-virus product.

If you have Fusion 2.0 release you could switch to the McAfee product instead? Just disable the Avast until the next release

and then renable after that.

This would allow you to have security, and networking and no delays.

Steve

Thanks. Steve

Dr_Gary · ‎02-17-2009

Steve,

Thanks for the input.

I may try the Mc Afee option...although, I have always experienced very poor performance on systems that are running Mc Afee AV products...

Gary

All