Bug 398446 - FUSE-mounted remote locations accessed with a KIO-using app are not visible in non-KDE open/save dialog
Summary: FUSE-mounted remote locations accessed with a KIO-using app are not visible i...
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: git master
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-10 02:30 UTC by Nate Graham
Modified: 2022-04-12 09:18 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2018-09-10 02:30:25 UTC
Let's say you use Dolphin to navigate to a Samba share, NFS location, FTP server, or Google Drive. All is well so far. You use Dolphin to open a file there in a non-KIO-using app like LibreOffice Writer, Inkscape, or Blender. All is well. You change the file and save it. KIO displays a dialog asking you whether you want to re-upload the changed file to the server, which is a bit annoying (see Bug 398216), but it works.

There is a problem, though:

The non-KIO-using app's non-KDE file picker cannot see the remote location. This means that you cannot use File > Open... to open new documents on the remote location, nor can you use File > Save As... to save a copy of the document to the remote location using.

There is probably nothing we can do about this short of secretly mounting the remote location using FUSE like GNOME's GVFS does (See bug 75324) and exposing the mount to the GNOME open/save dialogs, but I'm filing this bug anyway just in case anyone can think of something clever we can do anyway.
Comment 1 a.saoutkin 2020-01-02 18:29:48 UTC
Git commit fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1 by Alexander Saoutkin.
Committed on 02/01/2020 at 18:29.
Pushed by asaoutkin into branch 'master'.

Adding support for mounting KIOFuse URLs for applications that don't use KIO

Summary:
This patch is required to provide seamless integration with KIOFuse and KIO.

The patch attempts to convert URLs that applications will not understand
natively into local paths based on a KIOFuse mount. If successful, the URL
passed to the application is changed to its location within the KIOFuse mount.
If it is not successful, the URL is not changed.

If KIOFuse is not installed, then kioexec is simply used.
Related: bug 75324, bug 398216, bug 330192
FIXED-IN: 5.66

Test Plan:
Compile KIO with this patch.

Build and install KIOFuse (follow instructions in README): https://invent.kde.org/kde/kio-fuse

Once KIO is built, Dolphin is built with this newly built KIO, and kio-fuse is built,
one should start the kio-fuse process.

The easiest way to test this is via Dolphin (that is built with this patch): `dbus-launch dolphin`.

Once you have done the above one can simply browse to any non-local location in
say, Dolphin, where upon opening a URL in a non-KIO enabled app, it should open
in the KIOFuse mount, except for MTP/Gdrive URLs - those will use KIOExec.
Conversely, KIO URLs in KIO-enabled apps should not use KIOFuse.

Reviewers: fvogt, davidedmundson, dfaure, ngraham

Reviewed By: dfaure, ngraham

Subscribers: alexde, broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D23384

M  +1    -0    src/core/CMakeLists.txt
M  +45   -12   src/core/desktopexecparser.cpp
A  +9    -0    src/core/org.kde.KIOFuse.VFS.xml

https://commits.kde.org/kio/fcf4529f62e15cfc891757cf372c4ef7ee7ea4d1
Comment 2 Nate Graham 2020-01-02 18:40:02 UTC
I wonder if this will require changes to GTK.
Comment 3 a.saoutkin 2020-03-30 19:12:54 UTC
Hopefully in this case if the file opens in a KIOFuse mount they'll simply use the "save" functionality and hence won't run into this at all. If they choose to use "Save As" hopefully the dialog is smart enough to choose where the current file is currently saved (i.e. in the KIOFuse mount somewhere).

If not, I guess they're on their own. However, for dialogs that do exhibit this behaviour, I don't think we want to put up a patch upstream displaying the KIOFuse mount as a location, it'll be better if we patched it such that the behaviour in my paragraph above occurs, thoughts?
Comment 4 Nate Graham 2020-04-02 17:41:35 UTC
(In reply to a.saoutkin from comment #3)
> Hopefully in this case if the file opens in a KIOFuse mount they'll simply
> use the "save" functionality and hence won't run into this at all. If they
> choose to use "Save As" hopefully the dialog is smart enough to choose where
> the current file is currently saved (i.e. in the KIOFuse mount somewhere).
Generally this is true.

> If not, I guess they're on their own. However, for dialogs that do exhibit
> this behaviour, I don't think we want to put up a patch upstream displaying
> the KIOFuse mount as a location, it'll be better if we patched it such that
> the behaviour in my paragraph above occurs, thoughts?
Yes, in the cases where the above doesn't work, it should be fixed.

However what happens if, in the above use case, the user navigates somewhere else and realizes they need to get back to the FUSE mount location? They can use the back button, but having it visible in the Places panel too would be a nice touch IMO.
Comment 5 a.saoutkin 2020-04-02 18:54:48 UTC
I'm not entirely sure how much better that would be. They would then have to navigate all the way back to what they want. Usually a CIFS mount will be tied to just one share. But to get to a KIOFuse samba share, for example, the path would be / -> smb -> user@server -> (insert share folders and files here). Itself, / might do a dirlist with all sorts of slaves already mounted (mtp, sftp, smb, fish etc...), potentially confusing the user. 

More importantly , where would the patches be though. Do you only want them in KDE dialogs? Do we want GTK dialogs to display them. I know many apps that do their own thing altogether...

Do you want each individual mount point in KIOFuse to show up as a separate item, or just the slave?

One must also consider performance considerations. With the way the current KIO integration is done, the capability of KIO to cause blocking issues is reduced as much as can be. Even introducing KIOFuse into the places panel I believe can cause issues if it lags hard or deadlocks. In a typical scenario of opening files via Dolphin the only extra command needed is a KIO::stat -> KIO::get. We try to limit browsing inside a mount as much as possible. Allowing an easy way to do so can cause all sorts of issues. Some slaves have a substandard KIO::listDir implementation (MTP being an obvious culprit), and God forbid a user enables previews in a KIOFuse mount. One workaround I can think of, at least in open/save dialogs, is to force redirect to the remote URL if a KIOFuse mount is entered (as is done in https://phabricator.kde.org/D28290).
Comment 6 Nate Graham 2020-04-02 23:33:23 UTC
GTK dialogs already display FUSE mounts mounted by gfvs, just like Nautilus does. I was just thinking we should do the same thing, really. But I see your point that it isn't really needed for the Save case.

However it is definitely needed for the Open case, for reasons described in the original bug report.
Comment 7 Kyle Tirak 2020-05-13 13:01:25 UTC
It sounds like one unfortunate effect of this will be an inability for browsers like Firefox to directly save downloads to the smb share.
Comment 8 Maxim 2021-01-03 14:07:39 UTC
(In reply to Kyle Tirak from comment #7)
> It sounds like one unfortunate effect of this will be an inability for
> browsers like Firefox to directly save downloads to the smb share.

With firefox you can use gtk_use_portal option or use firefox from opensuse. In both cases - you got kde file dialogs/