...I don't know how to begin responding to that post.
If you are dis-satisified with OpenOffice than you can always try StarOffice.
I wouldn't reccommend StarOffice however, simply because SOLARIS sux!!!11
So I have the Beta 4 fusion release, installed the tools from a fresh
start, so ensuring any previous versions were removed.
I have a network drive mapped to my
I go through Explorer.exe to the drive and run under Public
share which maps to my \Users\steve\Public
and loaded powerpoint slides, word docs including the one from here,
excel spreadsheets and even wmv movies. No problem with
any of them.
The share is enabled read/write as I can create new copies of the
I can go through the cmd.exe to the same location on my network
drive and run the files and office applications load and load the
I even used explorer.exe to
.host\Shared Folders\Public and
double clicked the relevant office files and again all worked.
I even have the same permissions on those directories of Public
and DropBox that you listed (except obviously my user was my own).
Okay, more informational questions:
1) What is the VM operating system that you have installed?
2) Do you any anti-virus or file backup or file replication type
products installed in the VM operating system?
3) Would it be possible for you to manually force a crash dump?
there is a registry setting to allow you to do this using a specific
key combination. If you are willing to do this I will add the
required steps. It will involve checking that you can create
a "Complete Memory Dump" too. Once you have it maybe
we can compress it and upload that.
There is an interesting discussion going on in another topic in this forum:http://www.vmware.com/community/thread.jspa?threadID=88511&tstart=0
Fusion Beta 4 crash while writing to shared folders)
They say that avast antivirus causes crash while writing to shared folders. I did not mention that i also use avast antivirus.
It may well be that is my problem: Word crashes when tries to write back to shared folders, that is why opening files read-only works fine.
So it nothing to do with access rights, the culprit is avast antivirus.
Microsoft products and software using Windows APIs can crash for a variety of reasons when access files over the network. Sometimes it's the method used to retrieve a file attribute which results in an illegal procedure call, sometimes the latency, sometimes the file preview image is corrupt. I have seen Windows machines blue screen when touching a Word doc in Explorer on a Samba share.
The consistent problem though is
.host access (that's the UNC name right?) to the shared folders causes a lot of problems which simply go away when you map the drive.
Can you try disabling Avast product temporarily, rebooting the VM and
retrying to load the office docs, I can now get your issue reproduced as I have Alwil's Avast 4.7 installed and running?
(Try editing the registry if need be:
Ont thing I was going to try to disable version 4.7
was to edit the registry for their services/drivers and reboot.
For version 4.7:
AswMon2, AswRdr,AswTdi, AswUpdSv, avast! AntiVirus, avast! Mail Scanner,
avast! Web Scanner.
Each has a Start key and remember its value and modify it to 0x4
This will disable each driver and service for the next reboot.
Hopefully that should disable the relevant parts that would
get in the way of the IO stack. You can then retry the issues,
and always reset the Start values to their original settings and
reboot to get them enabled again.)
I will try and get the Avast anti-virus issue addressed and fixed too but
would like confirmation that it is what you are running into.
Okay, now I know what the issue is. It is an Avast driver (AswMon2.sys) error in the completion handling of the create file request.
They fail to handle the request correctly, which causes the IO Manager
to not complete the request and pass the results back to the user mode
application which in this case is Word, or other Office 2003 applications.
I am going to try a workaround for the HGFS.sys driver for our shared
folders, but will see if I can report this back to the Alwil guys.
I could have done this last week at Microsoft, but since I didn't know
about the issue then I never happened to talk to them, shame.
Steve, nice diagnostic work.
Do you know why accessing shared files through the shortcut with the UNC-naming scheme causes problems while the mapped drive does not? When I navigate the folders through the UNC-shortcut the window responsiveness borders "complete lock-up". The mouse-click takes about 1-2 seconds (sometimes as much as 20) to register the focus on a folder in the explorer window and the folder takes approx 8 secs to open. When navigating through a mapped drive to the UNC path there's very little latency 50-100ms (disk speed). Is this a DNS issue? Is there a config option in Windows registry to cache something to eliminate the problem?
Just to be clear (not to confuse terminology here or with brianriceca comment: http://www.vmware.com/community/thread.jspa?messageID=671828) I am talking about the shortcut to the share (UNC) name and a mapped drive letter to that UNC path (not a SMB share configured in OS X outside VMware)
Also, since you have such a good working knowledge of culprits of low-level conflicts with network file systems, do you have any insight into the causes of file attributes causing problems over network shares? This occurs a lot in environments accessing files from Windows desktops to unix backed (SMB/NFS mounts) or linux SMB shares --- is it a Samba bug, a Microsoft issue?
Thanks for your research and good work.
Your findings are a little too high-level to me, but anyhow i am happy that based on my post you or Alwil guys will make Fusion more robust.
Keep up the good work!
Hi the UNC naming sheme access to the shared folders seems to cause some issues for filters when they attach to the HGFS redirector when they
are okay with drive letter access.
There are a couple of issues that arise here, one being that the
.host and the
.host\Shared Folders\ directory are not real as in the usual sense for network drives. The HGFS network file system fakes up the required attributes for the "Shared Folders" directory and we probably have some incorrect error handling for the server component ".host".
I am going to investigate some of these issues and we will have a separate bug about this.
The lock up is probably due to HGFS driver communicating with HGFS server component, and I will investigate this too, to see if we can find the issue of
the delay here.
As for your last comment, file attributes being mapped from Unix/Linux environments to Windows I think will probably depend on some Samba configuration settings, but am not sure. However, not all file attributes are available on both systems eg Windows Hidden attribute, Read-Only etc. So the client LanManager in this case will have to get mappings dependent on the UNIX RWX settings for a file for the user/group/world. If you find bugs, then you should report them to Microsoft.
Check the samba config settings too though.
Not sure if that helps you.
FYI For those who like using Avast apparently others have reported that
they Avast just updated their anti-virus engine to 4.7.1029 and have reported that it works with shared folders.
So if you want to upgrade and retry this, please do, and if you find other issues or similar, then let us know.