SUMMARY Dolphin tries to process ".desktop" file, even when it is not a text file, and when it is big. This results in a unresponsive window. The solution is to set a size limit, on how big ".desktop" files Dolphin should process. STEPS TO REPRODUCE 1. Create a folder and copy a big file to it (150 MB) 2. Rename the file to ".desktop" or ".Desktop" extension 3. Browse the folder in Dolphin OBSERVED RESULT The window does not respond, the CPU goes high. I expect that Dolphin tries to process the big file, because it thinks it is a text ".desktop" file. EXPECTED RESULT Dolphin ignorees (do not process) big ".desktop" files, perhaps > 1 MB. SOFTWARE/OS VERSIONS Dolphin: 24.02.0 Linux/KDE Plasma: 6.0.0 (available in About System) KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION Nothing.
I can reproduce this on git master. If I change the extension of a large file to .desktop (>10mb) and open its containing folder in dolphin, it freezes up because it opens it as a desktop file in KFileItem::overlays(), which leads to the entire file being parsed in KConfigIniBackend::parseConfig(). Should this be moved from dolphin to frameworks-kio or frameworks-kconfig?
Out of curiosity. In which circumstances would you have a >1MB .desktop file ? Is it binary ?
(In reply to Méven from comment #2) > Out of curiosity. > In which circumstances would you have a >1MB .desktop file ? > Is it binary ? It was a DotNet single file like `app.android` and `app.desktop` etc. When you execute the file, it extracts the DotNet runtime and all program files. But even if the program was not a single file with the runtime, DotNet don't use `app.exe` on Linux, but nothing `app` and a `app.dll`. Anyway, in my opinion we must keep focus on the fact that a file manager should *not* freeze in such a way, just because a file is using the `.desktop` or any other extension. I have seen many examples on Stack Overflow where someone asks a question, and some people focus on the *why* instead of *how do we fix*. The *why* is okay, but should be the secondary focus.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/391
*** Bug 510874 has been marked as a duplicate of this bug. ***
Méven Car @meven, I saw that Nate Graham @ngraham asked: > What if there really is a config file that's greater than 1 MiB in size? Wouldn't this completely break the app that tries to load it? Could you for instance do something like this: if ( `.desktop` file is < then for instance 1 mb in size ) process it as normal. else if ( BOM indicates a text file using a supported encoding (UTF-8 etc.) ) process it as normal else treat is as a non `.desktop` file, and ignore I know that still leaves the possibility for a large text file without Byte Order Mark not being processed. Just a suggestion.
https://invent.kde.org/frameworks/kconfig/-/merge_requests/402
(In reply to René Paw Christensen from comment #6) > Méven Car @meven, I saw that Nate Graham @ngraham asked: > > > What if there really is a config file that's greater than 1 MiB in size? Wouldn't this completely break the app that tries to load it? > > Could you for instance do something like this: > > if ( `.desktop` file is < then for instance 1 mb in size ) > process it as normal. > else if ( BOM indicates a text file using a supported encoding (UTF-8 etc.) > ) > process it as normal A 50 MB text file is still an issue then. > else > treat is as a non `.desktop` file, and ignore > > I know that still leaves the possibility for a large text file without Byte > Order Mark not being processed. > Just a suggestion. You can look at the merge request to make suggestion or learn about the context.
https://invent.kde.org/frameworks/kconfig/-/merge_requests/391 should fix that, please try, thanks. We did have typo in commit, therefore this was not auto closed.