Bug 367878

Summary:	[KIO >= 5.25] Paste action disabled when copying local files to kdeconnect:// slave
Product:	[Applications] kdeconnect	Reporter:	Elvis Angelaccio <elvis.angelaccio>
Component:	common	Assignee:	Albert Vaca Cintora <albertvaka>
Status:	RESOLVED FIXED
Severity:	major	CC:	donjajo4all, ibelkov, simonandric5
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:	http://commits.kde.org/kdeconnect-kde/d89bf512cfa41fcc2dd6a57fdbff5cdbb40f53fc	Version Fixed In:
Sentry Crash Report:

Description Elvis Angelaccio 2016-08-26 21:14:40 UTC

The kdeconnect:// kio slave is affected by the same bug described in https://bugs.kde.org/show_bug.cgi?id=366795

To fix this, it should be enough to emit a valid (and writable) UDSEntry for "." in the slave's listDir() method.

Reproducible: Always

Steps to Reproduce:
1. Update to KIO 5.25
2. Try to paste some file to your smartphone

Actual Results:  
Paste action disabled

Expected Results:  
Paste action enabled

Comment 1 Albert Vaca Cintora 2016-08-28 09:10:51 UTC

I've tried making the same change and didn't work... 

Note that the kdeconnect KIOslave just redirects you to the mount point in the local filesystem after mouting it with sshfs, so it's probably not something we can fix just by changing parameters in our KIOslave.

Even if you don't use the kdeconnect KIOslave at all, the mounted filesystem doesn't let you paste. KIO bug maybe?

Comment 2 Elvis Angelaccio 2016-08-28 09:48:24 UTC

(In reply to Albert Vaca from comment #1)
> I've tried making the same change and didn't work... 
> 
> Note that the kdeconnect KIOslave just redirects you to the mount point in
> the local filesystem after mouting it with sshfs, so it's probably not
> something we can fix just by changing parameters in our KIOslave.
> 
> Even if you don't use the kdeconnect KIOslave at all, the mounted filesystem
> doesn't let you paste. KIO bug maybe?

I just tried to apply the same change to mtp:// and it seems to work. So indeed kdeconnect might be affected by a different bug...

Comment 3 Albert Vaca Cintora 2016-08-29 09:26:42 UTC

sshfs (used by kdeconnect) doesn't create the "." nor ".." entries, and hence it also shows this problem. I've opened a bug on their tracker [1] for them to fix it.

In any case, this might happen in many other filesystem implementations, so I think our old behaviour was more robust. Should we consider this a regression?

[1] https://github.com/libfuse/sshfs/issues/28

Comment 4 Elvis Angelaccio 2016-08-29 15:02:12 UTC

*** Bug 367936 has been marked as a duplicate of this bug. ***

Comment 5 Albert Vaca Cintora 2016-08-29 18:31:58 UTC

Git commit d89bf512cfa41fcc2dd6a57fdbff5cdbb40f53fc by Albert Vaca.
Committed on 29/08/2016 at 18:31.
Pushed by albertvaka into branch 'master'.

We should always emit an entry for "."

Note this doesn't fix the bug yet, as the KIO just redirects to the SSHFS,
which happens to have the same problem.

M  +24   -7    kio/kiokdeconnect.cpp

http://commits.kde.org/kdeconnect-kde/d89bf512cfa41fcc2dd6a57fdbff5cdbb40f53fc