| Summary: | Slow and high CPU when folder contain big ".desktop" file(s) | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | René Paw Christensen <rpc> |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | Antares0982, christoph, dolphin-bugs-null, kdelibs-bugs-null, mclangus, meven, nate, rpc |
| Priority: | NOR | Keywords: | qt6 |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kconfig/-/commit/6d23c7f5e4a354e394f12ed8e355609c32ac824c | Version Fixed/Implemented In: | 6.21 |
| Sentry Crash Report: | |||
|
Description
René Paw Christensen
2024-02-22 22:52:56 UTC
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.
(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. |