Bug 439886

Summary:	Remove `~/.cache/kioexec/krun/` and use regular temporary files instead
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	geisserml <geisserml>
Component:	general	Assignee:	KIO Bugs <kio-bugs-null>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	a.samirh78, geisserml, kdelibs-bugs-null, kilgore.trout, nate, nemeskey.david, postix, rlacroix
Priority:	NOR
Version First Reported In:	5.84.0
Target Milestone:	---
Platform:	Neon
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=439477
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description geisserml 2021-07-15 12:17:28 UTC

SUMMARY
KIO places downloaded files in the permanent cache directory `~/.cache/kioexec/krun/`, which persists across different sessions and is never cleaned up by the system. Users have reported this directory to grow enormously over time, unless manual measures are taken.
A persistent cache seems inappropriate for KIO downloads. Instead, regular temporary files should be used, placed in the system's dedicated temporary directory (QStandardPaths::TempLocation, https://doc.qt.io/qt-5/qstandardpaths.html). Temporary files have the advantage that they are cleaned up automatically on reboot.
Therefore, I would suggest to remove `~/.cache/kioexec/krun/` entirely and modify all components that currently rely on this directory to use temporary files instead.

STEPS TO REPRODUCE
Invoke a KIO download.

OBSERVED RESULT
The file will get placed in `~/.cache/kioexec/krun/`.

EXPECTED RESULT
The file should be placed in the temporary directory of the operating system.

SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.22
KDE Plasma Version: 5.22.3
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.3
Kernel Version: 5.8.0-59-generic (64-bit)
Graphics Platform: Wayland

ADDITIONAL INFORMATION
See also https://bugs.kde.org/show_bug.cgi?id=439477

Comment 1 David Nemeskey 2025-10-05 09:32:41 UTC

Fully agree. I found two videos in the directory which I am not even sure I opened with a KDE application aside from Dolphin. I might have opened them directly from the phone's DCIM directory. In any case, this is an unexpected and insidious behavior, and might cause serious problems for non-CLI-savvy users as there is no way to delete the cache on the GUI.

Comment 2 rlacroix 2025-12-13 10:15:25 UTC

I agree that this behavior is not fit for the main uses it will have (watching videos/opening big files from an external device/network share). No user will think about cleaning up himself the files so they should be deleted automatically. If for some reason using the .cache directory is mandatory, then just implement an automatic deletion of the files after X amount of time