Open polarathene opened 2 years ago
I have since discovered the VMX file setting isolation.tools.dnd.disable = "TRUE"
. This does not stop the CTRL+C
/clipboard implicit transfer behaviour for files. I have opened a separate bug #590 for that issue. Resolving that should technically resolve this one.
Drag and Drop functionality itself was tested. I could drag a large file from host to guest (dolphin file manager on each) and the file was copied to the drag_and_drop
cache folder, with Dolphin prompting at the target location if I would like to copy or move the file to the intended destination, thus avoiding a 2nd copy persisting in the cache folder.
Drag and Drop also worked as expected, no additional transfers occurred after the first explicit one. CTRL+C
/ clipboard transfer for files implicitly was probably an unintended bug? (or could be made opt-in by default?)
@polarathene Have you found a fix or a workaround for auto-pasting to drag_and_drop
issue? The auto-pasting seems to be case when using KDE, not for example MATE desktop environment.
@imenimus I have not investigated since the report.
You can disable DnD explicitly like mentioned, or you can disable copy/paste features explicitly too (see the linked issue #590 ). The bug with Ctrl+C causing an implicit copy (no drag/drop) I don't think has been addressed since, on the linked issue a maintainer responded with it being expected behaviour as far as they were concerned.
Their response did share an undocumented config that looks like it resolved the issue (I haven't been using VMPlayer too often to encounter the issue), perhaps try isolation.tools.copyPaste.File.disable="TRUE"
?
I may have some time spare soon to try again and update these two issues.
Describe the bug
~/.cache/vmware/drag_and_drop
receives file content from clipboard in both linux host and guest (depending on which is source/destination of a copy operation)./tmp/VMwareDnD/
maintains a symlink to those files.TL;DR:
Duplicate copies concern with filling up disk in host or guest aside, the copy to guest UX loop bug is the most frustrating one to workaround.
Reproduction steps
Expected behavior
VMwareDnD
/drag_and_drop
cache folders, or in addition hook into power management such as shutdown/reboot? Especially if clipboard entries are no longer valid, these contents will not be "pasted" again.Additional context
This is occurring with
CTRL+C
only. Despite the files automatically transferring/pasting to the "Drag and Drop" cache folders, no such drag and drop interaction is actually being performed explicitly.Personally, this was unexpected and not pleasant to experience with 50GB+ guest disk files on a host that were copied to an external disk and accidentally/unexpectedly transferred into a VM guest residing on slow local HDD storage. That particular experience was on Windows 10 and I do not recall being able to cancel the transfer at the time..
Environment
I could additionally verify with the following if desired:
Host:
vmware-worksation
v16.2.3 (AUR package)Guest:
open-vm-tools
: 12.0.0Example Screenshots
Guest screenshots of two files that were copied from the host triggering this bug. The host content did not change and the file was not explicitly copied on the host again, this is from interacting with the guest after a transfer:
Large file:![Screenshot_20220518_143904](https://user-images.githubusercontent.com/5098581/168950896-0bbbf607-dc35-4237-a3e8-234fd6c689b7.png)
Small file:![Screenshot_20220518_152540](https://user-images.githubusercontent.com/5098581/168950975-d873fb0d-1fdf-42eb-a04d-2e993af3af43.png)