Bug 425948 - kioexec regression with kdeconnect
Summary: kioexec regression with kdeconnect
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-29 15:03 UTC by Nicolas Fella
Modified: 2020-08-31 12:54 UTC (History)
4 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 Nicolas Fella 2020-08-29 15:03:40 UTC
STEPS TO REPRODUCE
1. Set default file browser to Nautilus or Thunar
2. Connect a device via KDE Connect
3. Run 'kioclient5 exec kdeconnect://<device id>'

OBSERVED RESULT
A folder with a single file named 'unnamed' opens

EXPECTED RESULT
A folder with the contents of the device opens


SOFTWARE/OS VERSIONS
KDE Plasma Version: master
KDE Frameworks Version: master
Qt Version: 5.15

ADDITIONAL INFORMATION

Relevant KDE Connect bugreport: https://bugs.kde.org/show_bug.cgi?id=413477

Reverting https://phabricator.kde.org/D29782 makes it work properly

FYI the kdeconnect slave works by setting UDS_LOCAL_PATH to a sshfs mount (https://invent.kde.org/network/kdeconnect-kde/-/blob/master/kio/kiokdeconnect.cpp#L249)
Comment 1 Ahmad Samir 2020-08-30 20:51:12 UTC
From the docs:
UDS_LOCAL_PATH
A local file path if the ioslave display files sitting on the local filesystem (but in another hierarchy, e.g. settings:/ or remote:/)

that matches what kdeconnect is doing, which is mounting the remote file system as an sshfs mount, however kdeconnect has "Class=:internet".

IIUC Class=:internet is for something like the sftp KIO, where the remote file system isn't mounted locally. I think this issue can be fixed by making the kdeconnect protocol Class :local. I tested that locally by editing kio/kdeconnect.json in kdeconnect-kde, and it seems to work.
Comment 2 Nicolas Fella 2020-08-30 21:41:00 UTC
Seems to work indeed, thanks!

From a KDE Connect POV this is resolved, I'll leave it up to you to decide whether to close it
Comment 3 Nicolas Fella 2020-08-30 21:46:53 UTC
Git commit 60a1adf2295d21d87fabed9c4d45cb70b6ad903e by Nicolas Fella.
Committed on 30/08/2020 at 21:45.
Pushed by nicolasfella into branch 'master'.

[kio] Mark Class as local

This is needed for kioexec to work properly since we forward to a local file system
Related: bug 413477

M  +17   -17   kio/kdeconnect.json

https://invent.kde.org/network/kdeconnect-kde/commit/60a1adf2295d21d87fabed9c4d45cb70b6ad903e
Comment 4 Nicolas Fella 2020-08-30 21:47:49 UTC
Git commit 56d40292470bb25253405b99d94792b72436a4d7 by Nicolas Fella.
Committed on 30/08/2020 at 21:47.
Pushed by nicolasfella into branch 'release/20.08'.

[kio] Mark Class as local

This is needed for kioexec to work properly since we forward to a local file system
Related: bug 413477
(cherry picked from commit 60a1adf2295d21d87fabed9c4d45cb70b6ad903e)

M  +17   -17   kio/kdeconnect.json

https://invent.kde.org/network/kdeconnect-kde/commit/56d40292470bb25253405b99d94792b72436a4d7
Comment 5 Ahmad Samir 2020-08-30 21:58:46 UTC
Looks fixed to me. :)
Comment 6 Harald Sitter 2020-08-31 09:20:14 UTC
Cool beans.

One could argue there should be runtime validation for this in StatJob.
If a :internet slave sets UDS_LOCAL_PATH that seems fairly indicative of using the wrong class.
Comment 7 Ahmad Samir 2020-08-31 11:06:42 UTC
(In reply to Harald Sitter from comment #6)
> Cool beans.
> 
> One could argue there should be runtime validation for this in StatJob.
> If a :internet slave sets UDS_LOCAL_PATH that seems fairly indicative of
> using the wrong class.

Excellent point; it also solves an issue of StatJob behaving differently based on whether you call:
 - KIO::mostLocalUrl, if the protocol Class isn't :local the job is cancelled, UDS_LOCAL_PATH is never looked at
 - KIO::stat/statDetails then job->statResult(), the Class isn't checked and UDS_LOCAL_PATH is used

StatJob should be consistent (that issue made me go in circles for a while, where it didn't work if the code in kdeconnect used KRun which went through KIOExec path (uses KIO::mostLocalUrl); and worked if I changed kdeconnect to use OpenUrlJob instead of KRun, the former uses StatJob::statDetails).

I'll see what I can do about that and submit an MR.

Thanks :)