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