To modify remote files (via ftp, fish or samba access) is a headhache in Linux. Is not only Krusader who is affected, is a general compatibility issue between linux desktop environments. An example will clarify: Any file opened FROM a QT libraries based file manager (Krusader, Dolphin) is opened using KIO, so if the application that open the file opened IN is not QT based too (Atom editor, Gwenview, etc), the file is copied locally to "~/.cache/kioexec". So, when user save it, the file is not saved to the remote connection really. Only when user close the application, user is asked about to overwrite the file (to the remote folder). Is really a headache to work in this non-realtime way. However, if a remote file is open FROM any GTK libraries based file manager (Nautilus, Caja, ...), KIO is not used, but GVFS, indistinctly if the file is opened IN a QT or GTK based application. That way, the user not need to exit from the file editor each time he save changes to the file. Please, is there any way to force krusader to call gvfs (like Nautilus or Caja) ALWAYS to avoid this great issue? Tnank you
Gwenview is Qt-based KDE software that *does* use KIO, so you shouldn't see this issue there. If you do, it's likely a bug in Gwenview or the way your distro has set up its desktop file (the gwenview executable should be called with %U, not %F). Unfortunately there isn't currently a great solution to this issue. As you've explained, it's simply a different way that KIO and GIO work. KIO would have to be rewritten or extended to provide the same kind of virtual mounts that GVFS does. There was a project to do just this: https://techbase.kde.org/Projects/KioFuse ...But it's been dormant for some time now. The best way to resolve the issue would be work on completing that project, porting it to QT5, and merging it back into KIO.
Sorry, I can't try just now the information you wrote about Gwenview possible local issue. I discovered all this problems at work, where we work in a Windows domain with a lot of Samba shared folders and, moreover, against a lot of remote servers thru FTP and FISH protocols. It's a pity that we are in 2018 and I can't recommend seriously Linux desktop environments for professional working on a LAN/WAN workspace. It's a constant headache (I'm using Linux for 6 years) to find problems like this that make a simple user to give up if he has not a free software conviction. I'll try to "wake up" KioFUSE developers, cause this is a "must" to work in certain development environments. Thank you for your very useful information
> We work in a Windows domain with a lot of Samba shared folders If it can be useful: I edit the /etc/fstab file, I create a .smbcredentials file, and from that moment I just use a mountpoint. Lately it was written an article that may be useful in some cases: https://pointieststick.wordpress.com/2018/01/17/videos-on-samba-shares/
(In reply to Toni Asensi Esteve from comment #3) > > We work in a Windows domain with a lot of Samba shared folders > > If it can be useful: I edit the /etc/fstab file, I create a .smbcredentials > file, and from that moment I just use a mountpoint. > > Lately it was written an article that may be useful in some cases: > https://pointieststick.wordpress.com/2018/01/17/videos-on-samba-shares/ Thank you Asensi, but I did that some years ago. However, each time user lost connection to LAN, KDE freezes trying to get access to the samba mountpoint. Even if user boot her system without LAN connection, to boot was a infinite process. So I discarded that solution some years ago ;)
> freezes trying to get access to the samba mountpoint Maybe those other links can also help anyone that reads this bug report: https://bugs.kde.org/show_bug.cgi?id=283366 https://bugs.kde.org/show_bug.cgi?id=379994 https://bugs.kde.org/show_bug.cgi?id=363185