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: | ASSIGNED --- | ||
Severity: | normal | CC: | kdelibs-bugs-null, kfm-devel, mclangus, meven, nate, rpc |
Priority: | NOR | Keywords: | qt6 |
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
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 |