| Summary: | Can't reopen remote files using common "File, Open recent" menu option | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] kiofuse | Reporter: | Rafael Linux User <rafael.linux.user> |
| Component: | general | Assignee: | a.saoutkin |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | betterkde, fabian, grahamperrin, hey, j.straight-kde, johnmaverick74, kde, kevin.legouguec, khanich.opensource, kio-bugs-null, kungfoobar, lubimov.maxim+kde, nate, olivier.delaune, pavel23dob, r2b2x3+kdebug, rafael.linux.user, silopolis |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=483055 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Looks like the problem here is that the app stores a kio-fuse path, but if the location backing that path hasn't already mounted, it doesn't get mounted when the app itself tries to access it, because it's not going through KIO. I can't replicate this as described mounting the file protocol and using LibreOffice. Although this is definitely possible between sessions, which at that point the FUSE path would be mounted under a different directory. Can you confirm if the issue occurs when you re-open the application in the same session, or two different sessions? I'm sorry, my fault. I forgot to write 2 steps: - Switch off o.s. - Switch on o.s. as I usually do every day. I didn't try if same issue between sessions. (In reply to Rafael Linux User from comment #3) > I'm sorry, my fault. I forgot to write 2 steps: > > - Switch off o.s. > - Switch on o.s. > > as I usually do every day. I didn't try if same issue between sessions. Ok that's unfortunately expected. However if the following two are done then this bug can be fixed: 1. mount KIO FUSE at /run/1000/kio-fuse/ instead of /run/1000/kio-fuse-<6-char-random-str>/. The reason why there's a random string is so that if KIO FUSE crashes for whatever reason, it can be DBus activated again. Otherwise, if KIO FUSe crashes and it is DBus activated again, it will be unable to mount as the previous process crashed and didn't unmount itself. I don't know if there's a way to call fusermount3 -u $dir upon crashing (which would allow us to remove the random string). 2. For the subsequent stat to succeed, the origin (i.e. protocol + authority) must already be mounted somehow. I'm not sure on the best way to proceed on that though... *** Bug 432631 has been marked as a duplicate of this bug. *** I have this problem too. After reconnecting, the path is different and I have to manually re-open all files/folders in applications. It breaks the workflow. I think it should detect if there's something mounted already before changing the path to a random one. Sometimes killing some daemon or even a reboot is preferable than re-opening files manually. (In reply to Alberto Torres Ruiz from comment #6) > I have this problem too. After reconnecting, the path is different and I > have to manually re-open all files/folders in applications. It breaks the > workflow. I think it should detect if there's something mounted already > before changing the path to a random one. Sometimes killing some daemon or > even a reboot is preferable than re-opening files manually. It's really a headache. I'm a programmer and use Visual Studio Code "projects" feature. If I reboot, then that feature doesn't work, cause saved path is not same in next o.s. session. My co-workers who use Windows do not have this problem. I've found a workaround for the time being: In dolphin go to the place, then press F4 and run: ln -sf "$PWD" ~/ Then use the linked dir in home instead of the /run path. Not ideal but not as bad as before. Or for all remote sites of certain protocol instead of just one: ln -sf $XDG_RUNTIME_DIR/kio-fuse-*/fish ~/kio-fuse-fish (replace fish by the desired protocol) (In reply to Alberto Torres Ruiz from comment #8) > I've found a workaround for the time being: In dolphin go to the place, then > press F4 and run: ln -sf "$PWD" ~/ > Then use the linked dir in home instead of the /run path. Not ideal but not > as bad as before. > > Or for all remote sites of certain protocol instead of just one: ln -sf > $XDG_RUNTIME_DIR/kio-fuse-*/fish ~/kio-fuse-fish > (replace fish by the desired protocol) It's really a good workaround while is fixed, THANK YOU However, in my case, is not a desirable way. I manage more than 25 servers (fish/ftp mainly, but SMB too) that I have bookmarked in Dolphin and Krusader (it will be great to have a common bookmark). From year to year, their local IPs are changed and I will waste too much time on adding so many links and - time after - changing them again. Anyway, I copy your great suggestion to my Evernote and will try with some server. Thank you again *** Bug 470795 has been marked as a duplicate of this bug. *** Hi, may I heavily pound on this one?! My take on this is that a[nother] "$HOME/$KIO_FUSE_ROOT" mount directory is needed for stable/permanent mounts. Actually, I'm using smb4k just because kio-fuse doesn't allow me to configure a stable mount path to some SMB shares I _need_ to find always in the same place, not to mention the other issues already evoked in this thread. But what about the other protocols? It seems what we are really missing here is the feature of the defunct kiofuse (https://techbase.kde.org/Projects/KioFuse) which simply allowed to specify a mount directory while using the great kio-fuse machinery. Or being able to define another/several fio-fuse roots and use https://github.com/KDE/kio-fuse/blob/master/utils/mount-url.sh with an option to select the desired root. That'd be a perfectly efficient solution, coupled with startup tasks. Nice and sleek :) For complete integration and user happiness, a simple (option in a relevant) panel in system settings could allow defining the additional, stable kio-fuse directory. Other settings in the panel would allow defining the list of stable mount points. A contextual menu action could allow adding targets to the list from the file browser. In the meantime, Alberto's symlink solution may be leveraged with a bit FS event monitoring, like watching apparition and disappearance of directories in kio-fuse directory and making iwatch/fswatch manage the symlinks automatically... (In reply to silopolis from comment #11) > It seems what we are really missing here is the feature of the defunct > kiofuse (https://techbase.kde.org/Projects/KioFuse) which simply allowed to > specify a mount directory while using the great kio-fuse machinery. You can already achieve this with a systemd dropin: mkdir -p ~/.config/systemd/user/kio-fuse.service.d/ cat >~/.config/systemd/user/kio-fuse.service.d/ <<EOF [Service] ExecStart= ExecStartPre=/bin/mkdir -p ${XDG_RUNTIME_DIR}/kio-fuse # Adjust path if necessary ExecStart=/usr/libexec/kio-fuse -f ${XDG_RUNTIME_DIR}/kio-fuse EOF (Or edit the dbus .service for non-systemd systems) However, the reason this is not already done that way is because it would not actually work in practice. Mount points are not persistent, so recent files still would not be found until something else triggers the mount. |
SUMMARY Despite KIO-FUSE implementation does its job, unfortunately, it's still a workaround. Yes, we can open and save transparently our remote files but indeed, they are working like temp files on local storage. When a user open a remote file with applications that use kio-fuse (usually GTK based for example "Visual Code Studio" or "LibreOffice"), kio-fuse does its job, despite is not a real remote file link, but a temporal local file. If user closes the application ("Visual Code Studio", for example) and reopen it and try to open again the remote file previously opened ("File, Open recent"), "Visual Code Studio" (or any application using kio-fuse) will show an error window telling "Path doesn't exist in path /run/user/1000/kio-fuse-qu ....." So, user CAN'T load that remote files cause the stored path in such applications are pointing to temporal local files instead real remote files previously opened. STEPS TO REPRODUCE 1. Open an application using kio-fuse and open with it a remote file 2. Close application 3. Open again that application and go to "File, Open recent/last files/documents" or similar OBSERVED RESULT Recent remote files can't be opened EXPECTED RESULT To open the remote file as any other available file opened SOFTWARE/OS VERSIONS Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.20.90 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.3.18-lp152.63-preempt OS Type: 64-bit