Created attachment 129500 [details] Demonstration of Dolphin becoming unresponsive while a FUSE mount is loading SUMMARY Opening [rclone](http://rclone.org/) or other FUSE-based mounts such as pCloud Drive makes Dolphin's UI unresponsive and completely unusable until the mount has finished loading. Other file managers such as Nautilus do not freeze when opening the exact same mounts. STEPS TO REPRODUCE 1. Add a remote to rclone such as OneDrive ([see rclone's documentation](https://rclone.org/onedrive/)) 2. Mount the remote 3. Open a folder on the remote that has many files in Dolphin 4. Wait for the remote folder to load and try to continue using Dolphin 5. Open the same folder in Nautilus 6. Try to use Nautilus while the folder loads OBSERVED RESULT Dolphin becomes unresponsive while the remote loads and no loading indicator is shown. Opening the same folder in Nautilus does not render it unresponsive and it correctly shows a loading indicator. EXPECTED RESULT Dolphin should remain responsive and show some sort of loading indicator while loading FUSE mounts just like it does for other remotes such as FTP. SOFTWARE/OS VERSIONS Dolphin Version: 19.12.3 Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-37-generic ADDITIONAL INFORMATION Originally reported on Reddit https://www.reddit.com/r/kde/comments/haxpfg/dolphin_freezes_when_opening_rclone_mounts/
Dolphin believes FUSE mount points are local, because they don't use a remote protocol. I am not sure if it is possible to ask the kernel if a local file path is actually remote, and if KIO needs to be changed or the change needs to be made in Dolphin.
(In reply to Christoph Feck from comment #1) > Dolphin believes FUSE mount points are local, because they don't use a > remote protocol. I am not sure if it is possible to ask the kernel if a > local file path is actually remote, and if KIO needs to be changed or the > change needs to be made in Dolphin. Would it be worth looking into how Nautilus (or gvfs) handles it? Maybe it just assumes all mount points are remote and always adds a progress indicator? That might make sense since some old local drives can be quite slow to read. This issue will probably become more important once kio-fuse is rolled out as, from what I understand, it will use FUSE to mount Google Drive and other remote folders.
Of course gvfs knows if a mount point is local or not, because gvfs created it. The question is, how an application using this mount point can learn if it is a local or remote file system. BTW, kio-fuse does the reverse: It offers KIO mount points for non-KIO applications as local paths.
(In reply to Christoph Feck from comment #3) > Of course gvfs knows if a mount point is local or not, because gvfs created > it. The question is, how an application using this mount point can learn if > it is a local or remote file system. > > BTW, kio-fuse does the reverse: It offers KIO mount points for non-KIO > applications as local paths. Oh. I clearly still don't understand anything about how all the components in Linux work. I'll leave this to the professionals :)
(In reply to Christoph Feck from comment #3) > Of course gvfs knows if a mount point is local or not, because gvfs created > it. The question is, how an application using this mount point can learn if > it is a local or remote file system. > > BTW, kio-fuse does the reverse: It offers KIO mount points for non-KIO > applications as local paths. KIO has a function called isSlow(), but it can also cause blocking.
I can reproduce this bug with rclone. Using dolphin is basically impossible when working with large remote file systems using FUSE.
I just have a folder with 500 files in it, just navigating folders is a pain. I'm not even trying to download the actual files themselves. Just browsing
I have been running into this issue with using onedriver to access OneDrive. I had seen a work around was to use Nautilus, and tried that today. There the behavior was as expected: my OneDrive files load quickly and Nautilus remains responsive in the default view. However, when I tried to switch from the gird view to the list view in Nautilus, it too started to become unresponsive. So I opened Dolphin, switched to the grid view there (I tend to use the details view mode usually) , and the OneDrive folder works without Dolphin becoming unresponsive. It did slow down a little as various file previews were loading, but never became fully unresponsive. I hope this bit of information is useful in tracking down what the actual issue might be (something with pulling metadata needed for the details view?) and also maybe provides a work around for other affected users (just switch to grid view).
I use Gigolo to automatically mount my SAMBA share from my other laptop (via GVFS). When I inserted an external USB drive, KDE Plasma (5.27.11) froze - taskbar, widgets, desktop, Dolphin also. Since I could switch between open windows - not Dolphin - I switched to Gigolo and disconnected the SAMBA share and immediately KDE Plasma and Dolphin started working. I'm on Kubuntu 24.04.1 LTS and Dolphin 23.08.5. SSHFS doesn't cause trouble - also through Gigolo.
This affects *any* slow filesystem when accessed through conventional mounts (i.e. not explicitly via kio). e.g. Sleeping/spun-down mechanical disks. Any kind of broken/disconnected/unresponsive mount. NFS/CIFS/FUSE/SSHFS etc. mounted by any mechanism besides kio (fstab, autofs, gvfs, etc.). Any of these will cause dolphin to become completely unresponsive (and often other parts of plasma as well), regardless of whether the affected path is currently in view or in any way critical to system functionality (note *all* mounted disks spinning up when opening dolphin on an unrelated path). Better yet, this will cause all open dolphin instances to freeze and any attempt to open a new instance to hang until all mounts are available and loaded, rendering a core component of the DE completely unusable. This has been going on (with minor variations) for at least a decade now, and the root cause is deeper than dolphin. See #448361, #474403, #454722, #492815, #441077, and many more I CBF tracking down. This been regularly reported (and promptly buried and forgotten) for years.
*** Bug 448361 has been marked as a duplicate of this bug. ***
*** Bug 454722 has been marked as a duplicate of this bug. ***
*** Bug 273045 has been marked as a duplicate of this bug. ***
*** Bug 442684 has been marked as a duplicate of this bug. ***
And the reports keep rolling in... 450696, 474403 This is a major usablility problem, one unique to KDE, and a class of problem (UI threads and desktop components blocking on unrelated I/O) that was solved in other environments as far back as 1995. Is it ever going to get any attention whatsoever?
We are collecting related bug reports so that we can look into this issue.We hear your frustration. At this point, comments that don't add additional useful data don't add anything to this bug report. Please respect the subscribers to this report and the developers and keep comments data related. Thanks!
The title of this bug report relates to FUSE mounts, but from what I can tell the same issue impacts *any* kind of mount (in my case, both NFS and local disks). Is there something about this that's fundamentally different with FUSE?
(In reply to miranda from comment #17) > Is there something about this that's fundamentally different > with FUSE? No, AFAICT. rclone fuse mounts are just an obvious case of "high-latency filesystem that's not explicitly accessed via a kio:// path". Local filesystems cause the UI to freeze as well if there's noticeable latency (e.g. a disk spinup or a stalled I/O queue) involved. Frankly I have no idea why this particular bug report is getting all the attention, there are dozens of other more general reports on the same underlying problem to choose from.
It's not only dolphin, but also the complete kde desktop freezes (can't move the mouse). When an NFS share HD is slow to write (especially when the drive gets close to being full), dolphin will freeze, and lately it is also regularly freezing the complete desktop (so it got worse, because in the past only dolphin was freezing). As the network drive clear it's write queue, it unfreezes, then later freezes again as the drive queue is full, etc... This is with the latest updated versions of everything, on archlinux. The NFS shares are mounted with fstab.