https://bugs.kde.org/show_bug.cgi?id=501798
Kevin M.C. <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om Status|REPORTED |CONFIRMED Ever confirmed|0 |1 --- Comment #12 from Kevin M.C. <[email protected]> --- Can confirm on Dolphin 26.04.3 / KF6 6.28.0 / Plasma 6.7.4 / Qt 6.11.1 / Fedora 44, rclone 1.74.3 (Google Drive remote). Dolphin decides where to store per-folder view properties in ViewProperties::ViewProperties(). For folders inside $HOME, it only routes storage away from the folder itself (into a local hashed store under ~/.local/share/dolphin/view_properties/) if KFileItem::isSlow() returns true. That check is a static fstype string match (cifs, smb3, nfs*, afs, fuse.sshfs, etc. see KMountPoint::probablySlow()). fuse.rclone isn't on that list, so Dolphin proceeds to write view properties as an xattr directly on the mounted folder, which fails silently since rclone's FUSE mount returns ENOTSUP for all xattr calls. Workaround in the meantime: move the mountpoint outside $HOME (e.g. /mnt/googleDrive instead of ~/mnt/googleDrive) and access it via that canonical path. Outside $HOME, Dolphin skips the xattr route entirely regardless of filesystem type. Note: a symlink from inside $HOME to the outside mountpoint doesn't work (I tried). Rather than expanding the hardcoded fstype allow-list to include every FUSE variant that shows up, wouldn't it make more sense to generalize the check to a runtime capability check, since KFileMetaData already has one: useDestinationDir = fileItem.isSlow() || !KFileMetaData::UserMetaData(m_filePath).isSupported(); This makes Dolphin treat any xattr-incapable filesystem the same way it already treats SMB/CIFS/NFS - storing view properties locally instead of on the folder - with no maintenance burden as new remote/FUSE filesystem types pop up. -- You are receiving this mail because: You are watching all bug changes.
