Accepted Solutions
Is Visual Studio unable to open the
.host\ paths even if you do it from Windows Explorer? I would blame Visual Studio for not coping with our HGFS UNC paths, since practically everything else works. Of course there may be some issue with the HGFS file system driver that contributes to it as well...
But the aspect of opening files using shared apps can definitely be improved. The current mapping for opening files via shared applications is done to "
.host\Shared Folders", as you noticed. We may be able to change it to use the mapped drive letter in a future update, but I can't promise anything. The drive letter is not always Z:, and not everyone has the mapped drive letter present, so it's not a trivial change to do.
As a workaround, if you always have Z:\ for Shared Folders, you can use a hex editor and change the path that is used for mapping the file location 
DISCLAIMER: While this shouldn't affect anything besides the shared folder path mapping, I'm not responsible for anything that happens to your VM or shared files. Do this at your own risk!
1. Make a copy of C:\Program Files\VMware\VMware Tools\VMwareUser.exe and open it in a hex editor.
2. Go to offset 0931F0, it should say *
.host\Shared Folders\* or 5C 5C 2E 68 6F 73 74 5C 53 68 61 72 65 64 20 46 6F 6C 64 65 72 73 5C 00 in hex.
3. Change it to Z:\<NUL>....<NUL> or 5A 3A 5C 00 ... 00 in hex. The in-between data shouldn't matter since it's a NUL-terminated string, but I would fill it in with NULs just to be safe. Be careful not to add or delete any bytes from the actual file, just overwrite existing ones (most hex editors have a strict "overwrite" mode).
4. Rename the original VMwareUser.exe to something else like VMwareUser2.exe (normally it's in use since it's running).
5. Place the modified version of VMwareUser.exe into C:\Program Files\VMware\VMware Tools\
6. Log out and log back in to Windows, and enjoy.
Looking at our code, that string is only used for mapping the shared folder paths when you open files, as well as browsing to the shared folder in Explorer using Virtual Machine -> Shared Folders or the Status Bar in Fusion. Both of them seem to work correctly for me after the change, but again, I'm not responsible for any possible mistakes, since we're dealing with editing an executable, not our source code.
.svg.png "xe"){kind=avatar}
Is Visual Studio unable to open the
.host\ paths even if you do it from Windows Explorer? I would blame Visual Studio for not coping with our HGFS UNC paths, since practically everything else works. Of course there may be some issue with the HGFS file system driver that contributes to it as well...
But the aspect of opening files using shared apps can definitely be improved. The current mapping for opening files via shared applications is done to "
.host\Shared Folders", as you noticed. We may be able to change it to use the mapped drive letter in a future update, but I can't promise anything. The drive letter is not always Z:, and not everyone has the mapped drive letter present, so it's not a trivial change to do.
As a workaround, if you always have Z:\ for Shared Folders, you can use a hex editor and change the path that is used for mapping the file location
DISCLAIMER: While this shouldn't affect anything besides the shared folder path mapping, I'm not responsible for anything that happens to your VM or shared files. Do this at your own risk!
1. Make a copy of C:\Program Files\VMware\VMware Tools\VMwareUser.exe and open it in a hex editor.
2. Go to offset 0931F0, it should say *
.host\Shared Folders\* or 5C 5C 2E 68 6F 73 74 5C 53 68 61 72 65 64 20 46 6F 6C 64 65 72 73 5C 00 in hex.
3. Change it to Z:\<NUL>....<NUL> or 5A 3A 5C 00 ... 00 in hex. The in-between data shouldn't matter since it's a NUL-terminated string, but I would fill it in with NULs just to be safe. Be careful not to add or delete any bytes from the actual file, just overwrite existing ones (most hex editors have a strict "overwrite" mode).
4. Rename the original VMwareUser.exe to something else like VMwareUser2.exe (normally it's in use since it's running).
5. Place the modified version of VMwareUser.exe into C:\Program Files\VMware\VMware Tools\
6. Log out and log back in to Windows, and enjoy.
Looking at our code, that string is only used for mapping the shared folder paths when you open files, as well as browsing to the shared folder in Explorer using Virtual Machine -> Shared Folders or the Status Bar in Fusion. Both of them seem to work correctly for me after the change, but again, I'm not responsible for any possible mistakes, since we're dealing with editing an executable, not our source code.
Great, an hex hack, I like those ! It works, too.
I also blame Visual Studio (although it may have advanced options similar to IE, but I doubt it), but I still think the .host scheme is weird.
As I said, Reflector fails too, both on startup and when loading files. Since yesterday I've updated it: it now explicitely says it can't be run from a networked drive, so that's settled. But it is able to open UNC files, yet fails on .host with a System.UriFormatException (see topic title). I believe all .NET apps using URI for file-handling will choke on those too... this is bad since .NET is so common on Windows!
I've now worked around this, I disabled all mirrored folders and manually redirected them to Z:\Ben\Documents/Pictures/Music (using "set location" on Windows Explorer), I think it's much cleaner that way, plus I can mirror more folders, like Videos, Downloads, etc. So this mapping should clearly be at least a vmx parameter (I agree you can't do it automatically).
Glad to see you agree with me regarding that .host madness 
!
Although access times using HGFS have improved considerably I'm still finding it slower than using SMB/CIFS.
Wow. Really? That's the whole reason I switched from SMB to HGFS... now you're telling me that I'm gonna get slower access times!? Hmm, now that I think about it, since I did the whole mapped drive thing, I should only have to remap from \ \.host to \ \MACPRO if I do want to switch...
Is there an overview of the whole SMB vs HGFS somewhere? So far I've noticed the troubles of HGFS vs NTFS (creates quite a lot of mess: $RECYCLE.BIN folder, impossible to hide files --like desktop.ini and Thumbs.db), but I don't know if it would behave any better with SMB.
Thanks for your feedback.
You're welcome, thanks a lot for your detailed answer! I'm impressed by the community and employees' patience, kudos!
BTW, if I'm talking nonsense or ask too much "but whyyy?" questions, just tell me "because I say so" ;). I'm over-curious sometimes, but I don't pretend to understand everything when it gets really technical!
However, all the other files and types that are not shown by Finder, as not so easy to determine in such a sweeping manner, but could be added to a list of which to return as being hidden.
We just have not done this as yet. It would require a small investigation as to make a comprehensive list of files which would require this.
Well... you could always start by the obvious offenders: $RECYCLE.BIN, desktop.ini and thumbs.db, and refine the list later on. I guess those will bug anyone after 2 minutes using HGFS.
The downside of doing this, is that those files can never have the hidden attribute removed, as you can from Explorer for other files, since it is always added artificially by the server. Or we
could but then would have to track state for the file which would be a pain, as it would have to be persistent across opens and reboots of the VM.
This is what I don't really get, and the reason I said I thought this fs is limited: why can't you "translate" (ie have the fs relay) a Windows attribute into a Finder attribute? I mean, since you can add it artificially for dot files, why can't you do it dynamically?
Even if OSX attributes aren't enough, can't you use OSX metadata --it's extensible right? Maybe that's what you meant by "track the state".
As for the HGFS being a network share, and not a true file system, you misunderstand how the shared folders feature works.
Firstly, others have asked this too, but here are some details:
1) vmhgfs.sys in the VM is a fully-fledged legitimate native Windows file system driver and interface. It supports the same file system interface that local file systems provide and support such as NTFS and FAT.
The only difference being is that it presents a network file system interface the same as Microsoft's SMB/CIFS (Lanmanager) mrxsmb.sys does.
By fully-fledged fs, I meant that it would appear as a hard drive to the host (eg visible in Windows disk manager). I'm not very savvy on those matters, this is just my personal definition... you know, from a user standpoint.
2) The reason for doing a network file system in the VM and using shares are that it gives the user the most flexibility of how much or little of the host file system they would like to expose to the VM.
This is a natural fit for shares and how they work, and how we have to share access to files in the VM with file requests from applications on the host at the same time.
I agree, since we're indeed sharing a folder, it makes more sense.
I guess it depends on what the user is trying to do, how he views his own setup. As for me, I'm looking at (ideally) totally abstracting the OS: I have one machine with resources (my files, a few devices), and a bunch of programs. Those can come from OSX or Windows, I don't care, I don't even wanna know. Same for the files, I'm more looking for total emulation, I don't care who is shared where.
If I could install my Windows programs on HGFS (wouldn't be wise perf-wise), I would, just so I could have Spotlight index them.
3) Making the HGFS file system appear as a local file system would make no difference to the APIs supported or even performance since we would still have to get the data from the host anyway.
Well, that's my point: it does make a difference (not perf-wise, API-wise). For example, Explorer doesn't auto-refresh the content of a folder in a network drive (if I delete/add a file OSX-side, I have to F5 Windows-side).
Also, some programs can tell the difference between a network drive and a normal one. I agree, it's edgy, and quite probably 99.9% of your users don't care.
It's just like the way you emulate a true hard-drive from a vmdk file, or like CD-ROM emulators: the CD has to (and does) appear as a real device, not just mounted as a share. Programs just can't tell the difference (in theory) (and some try hard ).
We cannot grab the host disk as whole thing exclusively and present it as a local disk in the VM as then the host applications would not see it or be able to access it. Fuse and extfs for Windows assume some sort of disk they can mount and have exclusive access too and just read/write the ext3/ext2 file system to that disk. We cannot do that in this scenario.
I understand the difference. So Fusion accesses the drive as a normal host program, and relays the files... but why couldn't this be totally transparent to the VM? Why can't you grab the disk non-exclusively, and still present it as a local disk?
On VMware Workstation, there is the possibility of adding a disk to the VM, stored in a partition instead of a file. I've never tried it: does the host still have access to that partition? I've always wondered why Fusion didn't have this option.
Secondly, admittedly, we have performance issues with HGFS currently, but they can be overcome with time, and not solved by making it appear as a local file system. They are constrained by the current design and some missing features which we are trying to address in the next few major releases.
Eh, so far I haven't noticed the problems that WoodyZ reported.
I tried to copy a large file (700Mb): I got 20-30 Mb/s (as measured by Vista) from SMB, and 50-70 Mb/s from HGFS, so yay, much faster! It could be very different with small files, but I don't have the tools to benchmark it --SuperCopier doesn't work on Vista :(.
I guess my case is special too: I'm a Windows person forced to work on a Mac, so Fusion is more important that OSX for me! Your average user is probably more a home Mac user that wants to play games...?
I'm not a switcher, I still prefer Windows (don't believe Their lies, not everyone switches!), but there are a few things that I like about OSX, and if it was possible I'd install it as a VM on my home PC. With the level of integration Fusion's achieved, I'd nearly be ready to go the other way around (get a Mac and put my PC in it)... maybe with Fusion 3 :smileycool: ?
The goal really is to abstract the OS, I think. For the user, all that matters are the files and programs, the OS doesn't mean anything anymore. Maybe someday we'll be able to have Vista index the hard drive, and replace Spotlight by Windows Search? Or the other way around, whatever floats your boat. Or install Ubuntu and replace the dock with the KDE bar (or whatever it's called).
While I'm talking crazy, I'll go even further: device abstraction. I have an Hercules webcam that doesn't have Mac drivers (and macam gives crappy results), so I plugged it on Windows, and I'm using Skype on Windows instead of OSX. But I still can't use the webcam on OSX programs. What if Fusion could use Windows' drivers and relay it back to OSX? This is probably insane and will make your engineers cry, but from a user point-of-view, that would be so cool! I don't care which OS handles my cam, I just want it available for my programs.
Well... enough dreaming for now! Cheers,
Ben