https://bugs.kde.org/show_bug.cgi?id=519624
RiverDoctor <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|REPORTED |CONFIRMED --- Comment #5 from RiverDoctor <[email protected]> --- Reporter of the duplicate bug 520647 here. I ran a bisection to test whether Nextcloud is actually causal or just a coincidence, and the result is clear: the running Nextcloud Desktop daemon is required to trigger the crash. I tested four scenarios on my system (Arch, KDE Plasma 6.6.5 Wayland, Dolphin 26.04.1, baloo-widgets 26.04.1), all using the original reporter's procedure (rename a file twice, then right-click the viewport): Non-Nextcloud folder, static contents — no crash. Non-Nextcloud folder with a background touch loop generating filesystem churn (while true; do touch /tmp/test/f_$RANDOM; sleep 0.5; done) — no crash. Nextcloud-synced folder, Nextcloud daemon running — crashes reliably. Same Nextcloud folder, same files, but with the Nextcloud daemon disabled (binary renamed so D-Bus and autostart respawns all fail) — no crash. So it's not the files themselves (xattrs, content) and it's not generic filesystem activity. It's specifically something the running Nextcloud Desktop daemon does. Most likely candidates: The Nextcloud KOverlayIconPlugin for sync status badges, which mutates KFileItem state asynchronously from a different code path than the context menu builder. The Nextcloud socket API the daemon exposes, which Dolphin plugins may query during menu construction. For reproduction on a clean test system: install nextcloud-client (which provides nextclouddolphinactionplugin.so and the overlay icon plugin), configure a sync, and right-click inside the synced folder while the daemon is running. Local-only Baloo tags don't need to be defined — I have none and the crash still triggers. Note: my own duplicate's reproduction path (repeated right-clicks for 1-2 minutes) and the original procedure (rename × 2 + right-click viewport) both converge to the same null-QUrl crash in TagsFileItemAction::actions, so these appear to be two paths into the same race. -- You are receiving this mail because: You are watching all bug changes.
