https://bugs.kde.org/show_bug.cgi?id=527838
Méven <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Ever confirmed|0 |1 Status|REPORTED |CONFIRMED --- Comment #6 from Méven <[email protected]> --- (In reply to internet.coma792 from comment #5) > I can reproduce the same problem with fuse.gocryptfs. It seems to be traced > back to a regression between KIO 6.30.0 and 6.31.0. It looks like this is > not specific to mergerfs or to dolphin: any local FUSE mount whose source is > not under /dev/ is now treated as slow. > > Environment: Arch Linux, Plasma 6.8.2, Frameworks 6.31.0, Qt 6.12.0, > Wayland. > > My home directory is a gocryptfs mount, so I noticed some issues right away > as soon as I got to the desktop. > > Syntoms on that mount with KIO 6.31.0 (all fine with 6.30.0) > - Folder icons set thought .directory are ignored; The default icon is > showened instead. > - The properties dialog (alt+enter) no longer shows the Details tab for > files and folders on that mount > - The same folder with the same .directory shown from /tmp displays correct > icon > > Cause, from diffin kio-6.30.0 and kio-6.31.0: > > 1) src/core/kfileitem.cpp, KFileItemPrivate::isSlow(): in 6.30.0 it only > treated Nfs and Smb (from KFileSystemType) as slow. In 6.31.0 it asks > KMountPoint::probablyslow(). > > 2) src/core/kmountpoint.cpp, KMountPoint::probablySlow(): the old explicit > check for "fuse.kio-fuse" was replaced by > > || d->m_mountType.startsWith("fuse."_L1) && > !d->m_mountedFrom.startsWith("/dev/"_L1) > > With the comment "Naive check, would be better for KmountPoint to > distinguish fuse blk from fuse dev itself in the future" > > gocryptfs, mergerfs, encfs and similar overlays are FUSE mounts whose source > is not in /dev/..., so they all match. As described in comment 2, isSlow() > returning true makes KFileItem skip reading .directory and the same slow > classification also hides the Details tab. This was an intentional change, fuse users are more likely to be network filesystem. We removed this as this is a blocking call, that blocks loading a folder, potentially indefinitely. mergefs case is even worse, it can be anything. I don't know whether we can or should address this, or this is just expected behavior. We could whilelist mount-points per-mount-points so local folders can still have .directory customization, if for instance the fuse mount can either reliably expose its underlying filesystem or if mount options can help deduce it. -- You are receiving this mail because: You are watching all bug changes.
