https://bugs.kde.org/show_bug.cgi?id=429067
--- Comment #4 from Méven <me...@kde.org> --- (In reply to Dashon from comment #0) > SUMMARY > I was having a hard time figuring out if kio-fuse was working because > applications don't seem to be able to access the locally mounted folder. > After manually going to the directory /run/user/1000/kio-fuse*/server_name, > I was able to confirm that dolphin was in fact using kio-fuse to mount the > sftp drive. However, when using the add network folder button in dolphin > under the remote section. None of the files accessed from that location > return the path of the locally mounted folder. An example of the problem is > when I drag and drop a file from dolphin while in a remote location to a > separate terminal instance. Since dolphin seems to pass the sftp://url > instead of the /run/user/1000/etc url. Command line utilities are unable to > make use of files on remote drives. Pressing the F4 button correctly shows > the full kio-fuse mounted path url. I can then copy this and manually > navigate to that directory and do what I need to do there. After confirming > that operations work with that url. I decided to quickly install nautilus to > see if it suffered from the same problem. If you drag and drop a folder from > nautilus into konsole the full locally gvfs-fuse mounted path url is given > to konsole instead of the sftp:// location shown in the path bar. This way > terminal commands can make use of them. It seems that gui apps such as all > the kde apps (of course), gimp, mypaint, and libreoffice seem to receive the > usable kio-fuse mounted path. I just can't seem to get that path into a > terminal. > > STEPS TO REPRODUCE > 1. Have kio-fuse installed > > 2. Mount a remote drive through the add remote ssh (sftp protocol) drive > using the add network folder shorcut in dolphin. It should be located under > the remote section in the Network folder. > > 3. Drag and drop or copy the location of any folder/file in the remote drive > to a terminal. Or try to open a file with a program that does not have > native sftp support. > > OBSERVED RESULT > Nothing will happen or the program will fail because the file url is > incomprehensible to the external program. An example would be running > mediainfo on a video file off of said network drive. If the url is the > sftp://etc one that dolphin returns. Mediainfo will just sit there. However > if it is the /run/user/1000/etc url mediainfo will work as expected. > > EXPECTED RESULT > I think dolphin should return the path url of the kio-fuse local mount > instead. The way that nautilus seems to do. > > SOFTWARE/OS VERSIONS > Operating System: openSUSE Tumbleweed 20201111 > KDE Plasma Version: 5.20.2 > KDE Frameworks Version: 5.75.0 > Qt Version: 5.15.1 > Kernel Version: 5.9.1-2-default > OS Type: 64-bit > Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz > Memory: 15.4 GiB of RAM > Graphics Processor: Mesa DRI Intel® HD Graphics 620 It seems like KIO-fuse vfs (kioworker impl) should expose either UDS_LOCAL_PATH, OR UDS_TARGET_URL in https://invent.kde.org/system/kio-fuse/-/blob/master/src/kiofusevfs.cpp?ref_type=heads#L1796(In reply to Sin Jeong-hun from comment #3) > Is this a bug or an enhancement? Because, I think the fix would be simple, > and yet it's 4-years old. > > If I open an SMB shared directory and double-click a video file, MPV plays > it fine, because Dolphin passes a converted local address to MPV. But if I > drag-and-drop the same file to the same MPV, MPV crashes, because Dolphin > passes the raw "smb://" address. Then, can't this be solved by passing the > same converted local address for drag-and-drop, too? Why pass different > addresses depending on double-click or drag-and-dropping? > > If for some historical backward-compatibility reason, drag-and-drop needs to > remain raw network address, how about having an option in the Dolphin's > configuration? It could allow users to choose whether to use converted local > address or the raw network address for drag-and-drop. kio-fuse must be special-cased to have another default url exposed to application, or default drop url in metadata should match the user expectations indeed. -- You are receiving this mail because: You are watching all bug changes.
