[BUG]: Large files in clipboard transfer repeatedly upon host to guest transition

[polarathene]

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.

• These transfers are not temporary, they persist in the cache folder across reboots of a VM/host. No cleanup is done via VM shutdown, or GUI offered. Users must rely on maintenance of this location to be cleaned up, or handle it manually themselves.
• Guest to Host transfer only incurs the copy once. Unless the clipboard copies something else, and then the earlier copied file into the clipboard again. Despite being the same content unmodified, it will transfer again, and does not appear to make any check for sufficient free space for the copy.
• Host to Guest transfer works in the same manner except it appears to have an invisible surface over the viewport beneath the transfer progress dialog prompt. The guest cannot be interacted with during this process while that surface blocks the mouse interactions. It also remains after the file transfer, attempting to interact with the guest by clicking anywhere in that viewport begins a transfer again, making another copy. The only way to prevent this is to go back to the host and copy some text or similar to remove the latest clipboard item.
• With larger files such as an OS install ISO, this is easier to notice due to the progress prompt. However, when a small file (eg a shell script that is only 40KiB) is transferred, this happens so fast that no dialog is raised. Some clicks will get through if clicking fast enough, but input seems to be blocked from keyboard.
• One other experience allowed interaction with some application windows, while other apps and desktop elements (eg the digital time/clock and app taskbar/panel) were unresponsive/frozen (clock did not update visually, this is difficult to reproduce).

---

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

1. Copy from host a large enough file for transfer to display progress dialog. Alternatively with small text files which will not produce a progress prompt but reproduce symptoms just as well.
2. Try to interact with guest. Transfer should occur.
3. After transfer completes, try to interact with guest with a mouse click. It should be blocked and trigger a repeat transfer, but writes a new duplicate into the cache folder.

Expected behavior

• Host to Guest clipboard transfer should not cause a looping transfer operation (file was transferred or cancelled, do not prompt again). Matching the guest to host functionality.
• Host to Guest and Guest to Host should not copy the same file to the cache if no changes are made, nor should a duplicate copy be made. Small files could be content hashed making source path irrelevant, larger files may need better heuristics such as a rolling hash or file attributes (hashed?) comparison.
• GUI option to explicitly empty the 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.
• Preferably not requiring 2x the storage to perform the transfer would be ideal, but I understand why it's handled this way.

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:

• I have access to a Fedora 36 host and guest install.
• I recall having this same problem on a Windows 10 host to a linux guest earlier in the year as well. It was very irritating during evaluation of VMware software.

Host:

• OS: Manjaro (Arch Linux), fully updated.
• Kernel: 5.17.6-1-MANJARO (with DKMS for VMware kernel modules)
• vmware-worksation v16.2.3 (AUR package)
• XFS filesystem, NVIDIA 1070 GPU (510.68.02 driver), X11 session (xorg 21.1.3), KDE Plasma 5.24 desktop.
• VMware Workstation Player: 16.2.3

$ vmplayer -v
VMware Player 16.2.3 build-19376536

Guest:

• OS: EndeavorOS (Arch Linux), fully updated.
• Kernel: 5.17.5-arch1-1
• XFS filesystem, 3D Accel enabled (2.20.0.0 vmwgfx driver, Mesa 22.0.3), X11 session (xorg 21.1.3), KDE Plasma 5.24 desktop.
• open-vm-tools: 12.0.0

$ vmtoolsd -v
VMware Tools daemon, version 12.0.0.34242 (build-19345655)

$ systemctl status vmtoolsd
● vmtoolsd.service - Open Virtual Machine Tools (VMware Tools)
     Loaded: loaded (/usr/lib/systemd/system/vmtoolsd.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2022-05-18 14:40:22 NZST; 47min ago
   Main PID: 330 (vmtoolsd)
      Tasks: 4 (limit: 9474)
     Memory: 6.6M
        CPU: 13.554s
     CGroup: /system.slice/vmtoolsd.service
             └─ 330 /usr/bin/vmtoolsd

Example 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:

Small file:

[polarathene]

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?)

[imenimus]

@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.

[polarathene]

@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.