Bug Report: Drag & Drop temporary cache is not cleaned up after successful file transfer

[Artem Chebykin]

Summary

VMware Workstation leaves orphaned temporary files in the guest user's Drag & Drop cache after a successful file transfer. The cache continuously grows and is never cleaned automatically, eventually consuming a significant amount of disk space.

Environment

Host

• VMware Workstation: <17.6.3 build-24583834>
• Host OS: <Windows 25H2 OS Build 26200.8894>

Guest

• OS: Astra Linux Special Edition <1.8.5.46>
• Desktop Environment: <Fly Desktop>
• VMware Tools: open-vm-tools 13.0.5 open-vm-tools-desktop: 13.0.5
• open-vm-tools-desktop: installed
• VMware graphics driver installed

Problem Description

Drag & Drop works correctly and files are transferred successfully between the host and guest.

However, every transferred file remains permanently stored in the guest cache directory:

~/.cache/vmware/drag_and_drop

The cache is never cleaned after the transfer completes.

Over time, this causes the guest filesystem to fill with orphaned temporary copies.

In my case the cache accumulated more than 21 GB of obsolete files.

Steps to Reproduce

1. Start an Astra Linux virtual machine.
2. Ensure VMware Tools/open-vm-tools are running.
3. Drag a large file (for example a 6–8 GB ISO image) from the host into the guest.
4. Wait until the transfer completes successfully.
5. Inspect:

du -sh ~/.cache/vmware/drag_and_drop

or

find ~/.cache/vmware/drag_and_drop

Expected Behavior

After the Drag & Drop operation finishes successfully:

• temporary files should be removed automatically;
• the cache directory should become empty (or contain only transient metadata).

Actual Behavior

The transferred file remains inside

~/.cache/vmware/drag_and_drop

indefinitely.

Each subsequent Drag & Drop operation leaves another complete copy.

Disk usage grows continuously until the user manually deletes the cache.

Diagnostics Performed

VMware Tools service is running correctly:

/usr/bin/vmtoolsd -n vmusr --blockFd 3

No process keeps the cached files open:

lsof +D ~/.cache/vmware/drag_and_drop

Output:

(no output)

This indicates that the files are no longer in use and could safely be removed.

The issue is therefore not caused by open file descriptors.

Additional Information

The problem is reproducible with both small and large files.

Manual cleanup:

rm -rf ~/.cache/vmware/drag_and_drop/*

immediately frees the occupied disk space without affecting VMware Tools.

This suggests that the cleanup phase after Drag & Drop completion is not executed or fails silently.

Impact

This issue can silently consume tens of gigabytes of storage on the guest system.

Users may incorrectly assume that their filesystem is filling up due to other applications because the cache directory is hidden.

Request

Please investigate why the Drag & Drop cleanup routine does not remove completed transfer cache files after successful operations.

[RaSystemlord]

To my knowledge, this is how it has always worked. In Windows, the "cache" is the temporary folder (whatever it is defined) and thus I cannot see any problem. Temporary files should be cleaned on a regular basis anyway - something which many users do not accomplish ... but that is another discussion.

Now on Linux, I see from your post that you have the files in a hidden folder, which makes the task vmware-specific.

I guess the justification for this kind of functionality is that the files will never get permanently deleted or hanging in two folders, no matter what you selected to do and what happened - move or copy. I mean, functionality is possibly shared with cut-copy/paste -functionality ... does VMware REALLY know what was successful and what was not? Obviously, questions for Development.

[Artem Chebykin]

If the operation is not completed successfully—for example, if the file transfer is interrupted before the file has been fully copied—then this incomplete file is written to the cache. However, as far as I understand, there is no mechanism to resume or complete the transfer of that cached file.

In this situation, VMware displays a notification informing the user that it was unable to transfer the file to the guest operating system. So, in this respect, the developers handle the failure appropriately.

However, when the transfer completes successfully, an additional copy of the file is still written to the cache, and it remains there indefinitely. Over time, these duplicate cached files accumulate and consume disk space.

Eventually, when the disk becomes full, this can seriously affect the guest operating system. For example, on Linux, the system may no longer be able to start the graphical desktop environment because there is no free disk space available. This can lead to significant problems, and inexperienced users may even lose access to their files if they are unable to resolve the issue.

I consider this to be a kind of resource leak. Although it is technically a disk space leak rather than a memory leak, it is still a bug that silently and gradually consumes storage space until it causes serious problems.

[Branko Lazarevic]

I always used Windows, both host and guest. When I copy files from host to guest, they are copied first to user's TEMP folder, and they stay there even after copy completes... until the guest is restarted. It looks to me as "this is by design", but I don't know why the copy needs to stay in TEMP folder until the restart even after the copy completes successfully.