SUMMARY When trying to move a large file on a remote share into a different directory within the same share, dolphin doesn't perform a move operation. Instead, it's doing a copy via kio-fuse and then a delete. This seems to only happen in dolphin. Doing the move operation via kioclient works fine: kioclient --interactive move smb://hostname/home/large_file.iso smb://hostname/home/new_folder/ STEPS TO REPRODUCE 1. Navigate to a remote share in Dolphin (eg. smb://hostname) 2. Cut a large file 3. Navigate to another directory in the same share 4. Paste the file OBSERVED RESULT Dolphin pops up a notification showing that it's moving the file from /run/user/1000/kio-fuse-XXXXXX/smb/hostname/home/large_file.iso to smb://hostname/home/new_folder/large_file.iso. From the speed and network bandwidth, it's apparent that the data is being downloaded and reuploaded. EXPECTED RESULT kio-fuse shouldn't be involved in a move operation across the same remote share. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 37 KDE KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION kio-fuse Version: 5.0.1-4.fc37.x86_64 dolphin Version: 22.12.0-1.fc37.x86_64
I did a bit more testing to try and track this down. The latest commit in `master` (https://invent.kde.org/system/dolphin/-/commit/1c4baff760c7975d17381f72029a145943b32ff6) still has this problem. Doing a git bisect shows that https://invent.kde.org/system/dolphin/-/commit/8d7e600f63a1961294dfe2c278a710b4ce0716e9 is the commit that first introduced the problem. Reverting that commit on top of `master` fixes the problem. The `release/22.12` branch also works because of the revert at https://invent.kde.org/system/dolphin/-/merge_requests/479.
The way I understand it currently, sandboxing requires that applications don't transfer files directly between each other. Instead, the files are first put into an available intermediate "clipboard" storage, and then on paste they are moved to the target application. This new code that tries to deal well with sandboxing didn't receive a ton of iterations so far, and it is very much possible IMHO that there are some conceptual weaknesses to it that haven't been addressed yet. I don't know much more about this than what I just wrote. I personally am somewhat worried how this whole deal will proceed because the gravest regressions that we have/had in Dolphin the last year were because of this change and so far I solved them by reverting the new code on/after release. This of course makes the experience of working with sandboxed/flatpaked/… Dolphin a lot worse. I hope someone will deal with the issues. For the upcoming Dolphin 23.04 release all the issues fixed by the revert will re-surface and then I might have to revert again.
Ilya, you fixed the last gravest bug of the portal, so I'll cc you here for notice. I hope we can enable this feature in Dolphin this year without many regressions for users of Dolphin without a sandbox, but I don't know how we'll get there.
Wrong Ilya :)
I had a quick test with Nautilus and it seems GTK folks don't use application/vnd.portal.filetransfer for gvfs-based sources
Ah, it was because I was testing with flatpaked Nautilus without access to $XDG_RUNTIME_DIR/gvfs. After giving the access, it exports the files, but I don't seem to be able to test further as it seems it doesn't matter what I do, samba always returns permission denied to me for usershares.
Although I can assume it works for GTK world given that they have transparent conversion between internal GVFS URLs and local file paths, always doing a local mount. Maybe KIO should do something similar? The bug about long exporting will be solved as well then.
(In reply to Ilya Bizyaev from comment #4) > Wrong Ilya :) Sorry, wrong Ilya. ^^ (In reply to Ilya Fedin from comment #7) > transparent conversion between internal GVFS URLs and local file paths, > always doing a local mount. Maybe KIO should do something similar? […] From my limited understanding there is no way around that. A solution that requires downloading of the file seems broken by design, unless I am missing an important detail.
Yeah, it seemed weird for me too, personally I too will be happy if this is removed as it prevents the API to work outside of KDE (and I'm using the API in a non-KDE application). Apparently ask Harald Sitter who first added the code?
(In reply to Ilya Fedin from comment #7) > always doing a local mount. Yes. That is what we are doing and that is the problem here, no? Or rather, its incomplete so it is bugging out. When you copy from smb://hostname/home/large_file.iso we fuse it into /run/user/1000/kio-fuse-XXXXXX/smb/hostname/home/large_file.iso so that foreign (& sandbox) applications can consume it. When you then paste it into smb://hostname/home/new_folder/ that URL does not get fused and so it's no longer a move operation but a get-put operation between the fuse and the KIO SMB. That being said, I am a bit wary of adding more fusing because of the performance degradation we are seeing with the existing limited fusing already - needs fixing of the existing performance problems before we can think about adding more IMO.
(In reply to Harald Sitter from comment #10) > Yes. That is what we are doing and that is the problem here, no? Or rather, > its incomplete so it is bugging out. Well, Felix says it attempts to download the file rather than to mount the share. If it consumes so much time due to mounting, maybe it should mount the share only once for all the files?
(In reply to Ilya Fedin from comment #11) > Well, Felix says it attempts to download the file rather than to mount the share. I don't really have knowledge on the technicalities, so I would trust Harald's statements over my own on this. I was talking about downloading because that is what is apparently happening for the bug reporter. Sorry if my limited knowledge on the subject lead to further confusion.