I created a virtual Gentoo i686 box using the stable kernel 2.6.25-r9. open-vm-tools don't work correctly when dragging and dropping files from host to virtual. Anything alse just works: automatic window resizing, drag and drop from virtual to host.... If the host is Gentoo AMD64: ========== after some investigation I found out that, at start-up, a directory inside /tmp/VMwareDnD is created. I'm writting this from within my virtual Gentoo and the directory's name is 0c166dd3. However, whenever I drag and drop a file from the host into my virtual Gentoo's Dektop, a new directory is created, for instance 8f8de1b4, BUT the file dragged and dropped is put inside the former directory, 0c166dd3. Maybe this second directory does not have to be created? Maybe open-vm-tools is mounting the wrong directory, the one not containing the file dropped? I can see the file in 0c166dd3. If I frag a second file, a third directory is then created (9d97dfbe), but this second file is put into the directory created after dropping the first file, i.e., 8f8de1b4, keeping the third directory, 9d97dfbe, empty. ========== If the host is Windows XP: ========== I can't even drop the file inside Gentoo virtual ========== Is this normal? Why don't the dragged and dropped files appear on my virtual Desktop? I use the stable KDE 3.5.9 for x86. It has nothing to do with bug id#236769, as creating the missing symlink c Reproducible: Always Actual Results: Drag and drop from host to virtual does not work. Expected Results: It works.
Oops, I did'nt complete the bug report. As I said, it has nothing to do with bug id#236769. What's more, version 0.0.20081010.123053 from the vmware overlay does not work, either. Any help is greatly appreciated, as I use my virtual Gentoo as a part of a teaching project. Thanks in advance.
Ok, this may just be normal behaviour, I've seen it when drag/dropping into windows guests, the file transfers, and makes it onto the box, but never gets moved to its final destination. The best I can suggest is to double check you've got the vmblock module loaded, and mounted within the guest (should show up on the mount command). All this *should* be done by the init script. Then also, when you're within X, make sure the vmware-user program is running (it should autorun, but that depends on using a system with the xdg specification). Please let me know if any of that helps or not...
(In reply to comment #2) > Ok, this may just be normal behaviour, I've seen it when drag/dropping into > windows guests, the file transfers, and makes it onto the box, but never gets > moved to its final destination. Do you mean open-vm-tools for Windows?? With my Windows guest in my Gentoo AMD64 box I use the regular VMware Tools by VMware, and they work. The problem I see is with a linux guest and open-vm-tools. > The best I can suggest is to double check you've got the vmblock module > loaded, and mounted within the guest (should show up on the mount command). > All this *should* be done by the init script. Yes. The module is loaded at start-up by the init script. I added vmware-tools to my default level. The mount command shows: none on /proc/fs/vmblock/mountPoint type vmblock (rw) > Then also, when you're within X, make > sure the vmware-user program is running (it should autorun, but that depends on > using a system with the xdg specification). I also double-checked this in the past. When I run the vmware-user command as a normal user I get: "Another instance of vmware-user already running. Exiting." Of course, this normal user belongs to the vmware group. > Please let me know if any of that helps or not... I really appreciate your help, but all those issues had been already checked. The combo kernel-2.6.24/open-vm-tools-0.0.20080414.87182 used to work. However, I was forced to update both of them because I was getting corrupted files during draggings.
Yes, I mean I've seen this with a linux host to a Windows guest, using the official windows vmware tools (open-vm-tools is only for linux). Also, you say you had it working previously, but then also say that it corrupted the transfers, which in my mind isn't working. 5;) Either way, this is likely to be a vmware problem, rather than a packaging problem. There's not a lot I can do about it I'm afraid. Sorry. 5:( If you want this fixed, you should probably file a support request with vmware (or, more likely, at http://open-vm-tools.sf.net/, since they're more likely to respond to people using officially unsupported OSes such as Gentoo)...
