https://bugs.kde.org/show_bug.cgi?id=441077
--- Comment #4 from Kai Krakow <k...@kaishome.de> --- (In reply to Nate Graham from comment #2) > In general, this is why KIO exists: to provide asynchronous, non-blocking > access to flaky network resources. When you bypass KIO and mount them > directly, you're undoing that protection. > > What kinds of things have you manually mounted and why? The mount in question is a samba share mounted over VPN when I work remotely at home. The problem with KIO is that it is not transparently available to all software, i.e. when opening a document with LibreOffice, it will be copied to a temporary directory, then copied back on save/quit. This removes the ability of LibreOffice to lock the file and detect concurrent changes of the source file. And it also breaks relation between the original file path and the path opened in the application: This is not what I expect to be transparency. Also, non-KDE programs cannot even parse the paths: Sometimes, KIO paths become directly passed to the program instead of copying the file to a local path first. CLI utilities cannot even be used to navigate KIO mounts. KIO should probably become a fuse module - which would then probably just introduce this exact reported behavior which KIO tries to avoid. KIO is nice if you exclusively only use KDE software - but that's quite unrealistic in practice. Also, it falls apart once you drop to the CLI level, which is what a lot of my workflow consists of. I'm actually using KIO for things like managing files over sftp remotely via Dolphin - and it works great then. But its field of use is very limited to me. Maybe comment #3 solves it for me. -- You are receiving this mail because: You are watching all bug changes.
