Please reread your own comment.
I was replying to your incorrect comment and conclusion. I am not starting any flame war, but giving you an honest update and asking you questions why you arrived at the conclusion you did. If you had read my May 29th and June responses and finally my July 11th reply on this thread then you would clearly understand and see that it has been given attention and it is under investigation and actively fixed as best possible right now.
Feedback that is useful and often very helpful but to suggest that you stated what our priorities are is and that this bug is low is very presumptive to say the least.
Sorry you felt that my response was not correct but you are expected to read the thread thoroughly and see that there is activity here and you not being ignored. I am only interested in one thing, that is making this feature work with the highest quality I can.
I hope you don't abandon this product and even feature, because I have not fixed this on your timeline.
Steve, I arrived at my conclusions based on the two-month delay between the reporting of a data corruption bug and your following response:
I am the developer for the Shared Folders feature, and I have been under the gun recently with lots of new stuff going on.
I have to report that the bug you have reported has been filed and accepted.
I have not had a chance to reproduce this issue and look into it just yet, but you have my word that I will do as soon as I get a chance.
I think it's fair for a person to assume that at the point you wrote this, the bug was not a high priority.
Do you have a paid support contract with VMWare, or are you a $39 retail customer? In the absence of the former, perhaps a reset of expectations might be appropriate.
I'm neither. I'm evaluating VMware. This started with me stating that I find it disconcerting that a data corruption bug was triaged as a low priority. The low priority bit was my assumption based on the thread statements and timing. Steve replied with a vehement argument that I'm mistaken, so perhaps I am.
In any event, I was merely observing that as a potential customer, it's a major turn-off to run into data corruption. It's very scary to see any sort of data corruption bug sit open for an extended period of time.
In my case, I'm evaluating VMware Workstation and Fusion for potential use in a dev ops project with Vagrant and Chef. I will likely recommend we stick with VirtualBox due to this bug. Will VMware feel any sort of loss from this decision? Probably not. However, I'll pass on VMware enterprise offerings for the data center as well.
Okay, so here is an example of how it often goes, and did go in this case.
The issue is raised as a bug at some point after the being raised on the forum, (responded to by someone or not) this can be immediately or even or after a few days or a week.
In this case, the bug was raised a few days and then completely misfiled and ended in some other unrelated groups queue.
That group's queue then got mistakenly, again, not triaged (or skipped over) for quite sometime, spending most of the two months since it was raised at that queue.
A developer triaging that queue eventually realized the error and it got redirected to the correct group, i.e., me, and I responded here.
Now, that is not the normal sequence events but that is what occurred in this case.
It was never intentionally set to any "low" priority of any sort.
At that point I scheduled it into my existing workload and outstanding issues to be fixed. Including some urgent high priority issues.
I have got help from Dominic's application that he attached and reproduced the issue and then investigated the issue. Along with another report that sounded like the same issue but a different way of manifesting itself.
However, also what can typically happen on these forums is that bugs do get filed but no-one responds to the posts from the VMware developer side.
So no mention of any bug filed or even fixes are relayed back to the forum users.
So please just be aware, that even if you don't get replies here, it doesn't guarantee that the issue is not being addressed or even looked at or given a low priority.
I know that is not ideal, but that it does happen. I have even replied to issues raised on behalf of other developers, and I know other developers have chimed in on issues to do with VMware Shared Folders.
What I will say, is that if you do have VMware developers responding to the thread, and have concerns about priorities and urgency and workarounds that may help, then please just ask first. You will probably get more details back which can often help clarify things for you.
There is an awful lot of points that need to be taken into account when we schedule work and bug fixes. (I cannot enumerate them all here.)
I also will let you know, that often developers own expectations of what is deemed the highest priority is sometimes not the case for VMware developer's own recommendation aside). Often in worse cases, these not articulated back to the user either. That being said, I often try and do mention when this is the case to users and why.
Here corruption bugs are high priority, and rare, as you might expect or indeed hope. In a case where it only occurs in an OS used by very few users, then it may pushed out a little (not totally ignored) if there are equally bad issues in OS platforms used by a very high percentage of users.
You are all free to make all the assumptions you want, but if someone is responding ask first, so you don't have to assume anything. If there are no comments from VMware people, then that is are fault if you make assumptions and they are wrong.
I hope this helps at least this case, and I hope when other issues are reported too.
Please always report your issues and please give as much information as you can about reproducing it. It is often very hard to replicate issues that can rely on some specific environment which is usually not at all obvious.
I also appreciate that you are placing so much importance on the VMware Shared Folder issue, as it indicates to me at least, that you do intend to make it a central part of your set up and usage. (Or I could be making the wrong assumptions there..)
PS I make no assumptions or distinctions on what the individual users case is in terms licenses or paying fees, but I do go on how many of our general customers from our usage data are likely to be affected by these issues, and the nature of the issue and whether it can avoided by a sensible workaround or not (along with many other issues our Program Manager raises too).
I am also having this issue on my Vagrant development environment. My use case is a little different: I am doing web development with Node.js and I use a Grunt plugin that checks when a file is changed to automatically perform a browser reload. Whenever that plugin is enabled, this problem starts to happen.
This is the plugin that I've mentioned:https://github.com/gruntjs/grunt-contrib-watch#optionslivereload
Would appreciate any update on the resolution of this issue.
apologies for the long delay here.
I am in the process of checking in what I hope is the last set of changes to address this issue. There have been multiple changes required.
It should be not too long before these changes then make it into a release update which you will be able to pick up.
Thanks so much for your patience and understanding.
I just updated to the latest Version 6.0.2 (1398658) and the problem remains.
I am sorry to say this, but I am also very unsatisfied. VMWare is a tool I've used everyday to work with Vagrant, and it has become unsustainable to continue like this.
Can you give us an update on this? How much longer will it take for this to be properly fixed? A day? A month? Or should I gave up and use Virtual Box instead?
I am doing Android development on an Ubuntu 10.4 LTS VM on my MBP. I was running Fusion 5.X and could do a full build (kernel + userspace stuff) when the source tree was on an Ubuntu virtual disk, but when I tried the same thing on a shared folder that pointed to an OS X case-sensitive filesystem, I would get strange build errors such as the linker complaining about corrupted symbol tables, the clang compiler getting segment violations and so on. I read this thread and was excited to see that a fix was available, so I purchased Fusion 6.0.2 last night, fired off a fresh build and still the problems persist. So now I'm back to using NFS to share OS X mounts with my Ubuntu VM.
Sorry to hear that and I am somewhat surprised. You definitely have the latest vmhgfs version loaded and running I assume.
I tested with the test script I used to generate this issue on three different OS versions with different Linux kernels and they all worked fine.
Can you please tell me more about your environment and what you are doing exactly to generate this issue?
E.g. version of Linux and uname -a output, exact steps of your development maybe an strace output while accessing the files etc. you can send to me directly?
Thanks and sorry to hear that the changes have not improved things for you.
Hey Steve, this issue (or a similar one) seems to happen on one of our development machines since yesterday. It's really confusing, since we have almost the same environment on many development machines and it just appeared out of nothing.
We use: VMWare Fusion 6.0.2 (latest of now, according to the update mechanism in VMWare) on Mac OSX 10.9 Mavericks, also latest of now.
What happens? When extending files (adding more bytes to it) everything works as expected: the changes are visible within the virtual machine. When removing bytes somewhere in the file, it only decreases the size by removing the same amount of bytes from the end of the file. It seems that when working with vi or TextEdit, everything is synced correctly, but when working with Sublime Text 3 this occurs. We don't know whether it only happens with ST3 or any other application.
I have the same issue on Fusion 6.0.2 with VMWare Tools up-to-date and same configuration : files on OS X 10.9 shared via HGFS to Linux.
File read via OS X is correct. File read via Linux on VM is truncated at end. Adding 1 byte to the file fix the issue.
Occurs with Sublime Text 3 but not with Coda for example. I filled a ticket at sublime text as well Sublime Forum &bull; View topic - Save not reliable
It may be a saving method Sublime Text uses that is not handled correctly by VMWare Tools and HGFS...
Thank you for keeping this issue high in your priority list, I'm also a customer that bought Fusion to be sure to have a dedicated team listening to customers
My two cents
Does anyone have this working anywhere? Same file, twice opened separately, with non-synchronized updates and not getting the file blitzed/corrupted ???
As I recall from Programming 101, you get what you asked for, garbage.
I am getting this same problem on VMWare WorkStation.
Product: VmWare Workstation 10.0.1 build-1379776
Host OS: Ubuntu 12.04 bit (Kernel 3.2.0-56-generic)
Guest OS: Ubuntu 10.04 64 bit (Kernel 2.6.32-38-server)
Typical use case:
1. Run python file in guest
2. While python file is still running in guest, edit python file on host using Emacs
3. Stop and start python file in guest
Python file will be truncated to some arbitrary location
If you read the history, you'll see it's a single writer, multiple readers. Readers should still see states of the file that don't include insertion of garbage.