STEPS TO REPRODUCE 1. Have an NTFS (not sure if the FS is relevant) HDD with 9k picture files 2. View mode any 3. No previews 4. Go to $RECYCLE.BIN (the ntfs trashbin folder), select all files and right click OBSERVED RESULT Dolphin starts to freeze. Journalctl logs ``` ... ark.kerfuffle: Could not detect mimetype from content. Using extension-based mimetype: "image/jpeg" ark.kerfuffle: Could not detect mimetype from content. Using extension-based mimetype: "image/x-sony-arw" ... kioworker[13575]: libKExiv2: Cannot load metadata from file (Error # %1: The file contains data of an unknown image type ) ... kioworker[13575]: qt.gui.imageio.jpeg: Not a JPEG file: starts with 0x02 0x00 ... ``` EXPECTED RESULT Dolphin does not freeze. I had intended to delete all files directly w/o moving them to the trash by using the context menu. When I just hit DEL, Dolphin copied the files into the same $RECYCLE.BIN folder as copies. That's definitely another UX issue. ;-) SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250211 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.1-1-default (64-bit) Graphics Platform: Wayland
Thanks for the bug report. Can you please attach a backtrace of the freeze using the `coredumpctl` command-line program, as detailed in: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl Thanks!
Created attachment 178686 [details] Flamegraph There's no coredumped and I couldn't get a useful trace with gdb, but here's a flamegraph generated with hotspot. It shows that Dolphin considerably long hangs in > DolphinContextMenu::addItemContextMenu() (inlined) (dolphin) and below. because of mime data acquisition takes so long.
^
Thanks for the flamegraph!
I can confirm the context menu is slow even on m.2 drive when ~800 folders are selected. Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.12.15-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: AMD Radeon RX 6600
Looking at this with Hotspot, seems most cycles go to following: After: DolphinContextMenu::addAdditionalActions(KFileItemListProperties const&) - CompressFileItemAction::actions(KFileItemListProperties const&, QWidget*) - ExtractFileItemAction::actions(KFileItemListProperties const&, QWidget*)
I moved this bug to Ark, since I think it's on Ark side that the creation of actions takes long time for huge URL lists. Feel free to move back to Dolphin if any dev disagrees.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/ark/-/merge_requests/281
I've made a merge request that speeds up making the compress context menu, and which should also remove the delay when clicking on the "Compress to..." dialog, because it reuses the filename prefix which was already computed for the names of the actions like "Compress to abcdef.tar.gz". I'm now looking into the extract context menu, and I don't see much that can be done to stop it reading all the mime types. One idea I had was to use the KFileItem mime type, which is probably already computed, but we use Kerfuffle::determineMimeType() which has some logic specific to archive mime types which I don't think can be touched. To me it seems like the best solution would be to only create the extract context menu if every selected file is an archive file type. That way if we have a bunch of files selected, we can bail early if one of the files isn't an archive. This is what the Gwenview "Start a Slideshow" context menu service does when not every selected file is an image. Would anyone have a problem with this?
A possibly relevant merge request was started @ https://invent.kde.org/utilities/ark/-/merge_requests/283