[Bug]: macOS VFS - many GB of tmp files

[drybx]

⚠️ Before submitting, please verify the following: ⚠️

• [x] This is a bug, not a question or a configuration issue.
• [x] This issue is not already reported on Github (I've searched it).
• [x] Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• [x] I agree to follow Nextcloud's Code of Conduct

Bug description

I have lots of data under ~/Library/Containers/com.nextcloud.desktopclient.FileProviderExt/Data/tmp (about 20GB) that doesn't disappear on reboot.

Is that supposed to be this way?

Steps to reproduce

1. Right click on the file
2. Click on Share Options
3. The share dialog does not display the option to share by e-mail ...

Expected behavior

Temporary files get deleted automatically

Which files are affected by this bug

CFNetworkDownload_Iw0TpG.tmp and many many others

Operating system

macOS

Which version of the operating system you are running.

macOS 15.7.1

Package

Official Linux AppImage

Nextcloud Server version

32.0.1

Nextcloud Desktop Client version

4.0

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 3.16.3 to 3.17.0)

Additional info

I'm using VFS

[Rello]

Hello, do these files have a timestamp? are they recent files? I am using 4.0.1 and do not have any single file here

[i2h3]

The location is odd and not the usual temporary directory. They might be leftovers from a transfer in progress which was interrupted by a crash or something like that. Do the files reappear when being deleted manually?

[drybx]

Hello, do these files have a timestamp? are they recent files? I am using 4.0.1 and do not have any single file here

Most of the files were about 10 days old. Some were created yesterday though. I deleted the old ones now and will keep an eye on it. Right now there is one 1GB of data left in there.

[SeanWang98]

~/Library/Containers/com.nextcloud.desktopclient.FileProviderExt/Data/tmp found approximately 77GB of files, with folder names in roughly two formats, __fpfsdocID(27466) and 0A6A5DB5-E839-4237-AAEE-14D7DFC667CD, file dates traceable to the day I installed the client

[i2h3]

For the record: names like __fpfsdocID(27466) equal the internally used file provider item identifiers for file system items as managed by macOS.

[Flegelhaft]

I am having the same issue. Upon closer inspection the folders' (named in a scheme like __fpfsdocID(27466)) sizes match some large files i uploaded recently. Inside the folders are what i suspect to be those same files broken down into in chunks of 104,9 MB. Some of those uploads were interrupted and had to be reinitialized. Those appear twice in said folders, see screenshot as reference.

The folders remain in place even after deleting the corresponding uploaded files from nextcloud and take up a substantial amount of space.

[i2h3]

It is not a challenge to implement a cleanup for that temporary directory. The tricky part is the question: when? Because file provider extensions are highly concurrent and there can be multiple processes (at least I observed that in the past) at once.

The hint with the upload is good, I need to take a look at the upload code and it might even reach down to NextcloudKit. Safest and cleanest bet would probably be to swipe the folder once on file provider extension initialization or better invalidation.