KDE Connect version 1.0.3-1 KDE 5.36.0 / Plasma 5.10.4 Qt: 5.9.1 Kernel: 4.12.3-1-MANJARO I've been sending mp3 podcast files to my Android device through KDE Connect wireless "send a file" option. It worked relatively fine (only possible to system memory, no external card accessible that way) but lately any file that I sent becomes corrupted and players either stop playing them after few seconds or skip parts of the recording. I rechecked it and original mp3s are fine and get unusable after sending them through KDE Connect. When I use cable, then mp3s are fine. The only thing that comes to mind is some update (KDE Connect itself, framework, qt?) that may have caused it. Can anyone check if that's some general bug or just for me? I cannot find anything on that and I have no idea where to turn to help with such problem.
How were you sending the files? a) right click on the file -> send to <device> using kdeconnect or b) copy the file, open the phone from the places menu, paste the file
(In reply to Albert Vaca from comment #1) > How were you sending the files? > > a) right click on the file -> send to <device> using kdeconnect > > or > > b) copy the file, open the phone from the places menu, paste the file I click on KDE Connect tray icon and then click on folder icon, which opens dolphin file manager. From there I move to the place I need.
I can reproduce this issue on Arch Linux. Copying any file from my computer to my phone using sshfs (i.e., opening the remote filesystem viewer in dolphin) results in corruption of the file created on the phone (md5 checksums do not match). However, using the 'send to device via kdeconnect' context menu option does not result in file corruption. Also, using the remote filesystem viewer to move files from one folder on my phone to another does not result in corruption. The corruption only seems to occur when files are moved between devices. I am using version 1.6.5 of the android app (latest version in the Google Play store), and version 1.0.3 of the kdeconnect program. I am not sure what other information or logs may be useful here, so feel free to ask.
When I right click a file and choose the option "send to <device> with kde connect" it does nothing. I cannot use it to send any files. When I open my device from places in Dolphin it opens sftp mount: /home/username/.config/kdeconnect/fe7b01a9475a2ad7/kdeconnect_sftp/fe7b01a9475a2ad7/storage/emulated/0/Folder-Phone/ It doesn't matter if I drag/drop the file or copy/paste it, it results with corrupted file. I checked other file types and with small ones, md5 sums are the same. But with larger files (like 10MB+) sums are different so it's not only mp3s are affected but the whole transfer of larger files. This is serious and excludes usage of KDE Connect wifi transfer. The question is, is it caused by KDE Connect or another system element and then we should file a bug in another place? Using cable with mtp connection all is fine.
On further checking, I can confirm that the corruption happens only in the case of files above approx 128 KiB in size, when using the remote filesystem viewer.
This seems to be a bug in sshfs. Sshfs 3.0.0 exhibits this bug. However, if I downgrade sshfs to 2.9, the bug does not occur. Sshfs 3.1.0 was released a few days ago [https://github.com/libfuse/sshfs/releases], and the changelog for 3.1.0 mentions a fix for data loss issues which looks like it might be related to this. I will comment back whether sshfs 3.1.0 fixes the issue.
I can effectively confirm that this is an SSHFS 3.0 bug, which has been fixed in 3.1 but for some reason reintroduced in 3.2 (??). We already have a fix for it on the desktop side [1], that disables the buggy feature of SSHFS. But, since we can't guarantee distros are gonna adopt the fixed version of KDE Connect before they adopt SSHFS 3.0 (or 3.2) I've also written a "fix" for the Android app, which will just abort the transfer with an error. This way, at least we don't cause data corruption/loss. [1] https://commits.kde.org/kdeconnect-kde/aec736fe562f7bf35663557ba6629fa53bc45a71 [2] https://commits.kde.org/kdeconnect-android/83c8a30a715470ff7208bd217d3373a34ecd7e98
Thank you kishore96@gmail.com. Now at least we have something to watch and hope for fix.
(In reply to Albert Vaca from comment #7) > I can effectively confirm that this is an SSHFS 3.0 bug, which has been > fixed in 3.1 but for some reason reintroduced in 3.2 (??). > > We already have a fix for it on the desktop side [1], that disables the > buggy feature of SSHFS. But, since we can't guarantee distros are gonna > adopt the fixed version of KDE Connect before they adopt SSHFS 3.0 (or 3.2) > I've also written a "fix" for the Android app, which will just abort the > transfer with an error. This way, at least we don't cause data > corruption/loss. Does that mean, when we update KDE Connect and will have faculty sshfs version, transfer fail? If I didn't know the cause, I would see it as bug as well ;). Maybe some additional info with that error would be helpful to understand what is going on for people who didn't see that thread?
(In reply to Michał Dybczak from comment #9) > (In reply to Albert Vaca from comment #7) > > I can effectively confirm that this is an SSHFS 3.0 bug, which has been > > fixed in 3.1 but for some reason reintroduced in 3.2 (??). > > > > We already have a fix for it on the desktop side [1], that disables the > > buggy feature of SSHFS. But, since we can't guarantee distros are gonna > > adopt the fixed version of KDE Connect before they adopt SSHFS 3.0 (or 3.2) > > I've also written a "fix" for the Android app, which will just abort the > > transfer with an error. This way, at least we don't cause data > > corruption/loss. > > Does that mean, when we update KDE Connect and will have faculty sshfs > version, transfer fail? If I didn't know the cause, I would see it as bug as > well ;). Maybe some additional info with that error would be helpful to > understand what is going on for people who didn't see that thread? There is no way to surface this error to the user in a backwards compatible way :( It might be seen as a bug, but I think it's way better than just succeed with a corrupted file.
(In reply to Albert Vaca from comment #10) > There is no way to surface this error to the user in a backwards compatible > way :( It might be seen as a bug, but I think it's way better than just > succeed with a corrupted file. I agree. But error message comes with a message, right? Why not create some condensed, smart message that will shed some light? Like for example: "Error, faulty sshfs version detected (3.0 and 3.2)" Yeah, I know, it's also bad way to show it. But maybe with some brainstorming, it will be possible to design error message in a more informative manner? Hmmm... "Error, sshfs version 3.0 and 3.2 are not supported." It's still cryptic but at least it looks like a design and not a bug. Or maybe add: "Error, sshfs version 3.0 and 3.2 are not supported due to a serious transfer bug" This is bolder and less eloquent message but I'm not sure how shorter this could be explained. Of course, that's just my proposition and I trust KDE Connect development team will choose the best solution or wording of that message. Maybe use some words that allow users find easier the info about that sshfs bugs?
As a better temporary fix for this, would it be possible to mount the phone's filesystem with the '-o writeback_cache=no' option? According to this issue (https://github.com/libfuse/sshfs/issues/72), it looks like that might mitigate the data corruption.
That is actually the fix, but we can't change that without a desktop release.
(In reply to Albert Vaca from comment #13) > That is actually the fix, but we can't change that without a desktop release. When can we expect a release containing the fix?
I wanted to do it last week, but I didn't find the time. It should happen soonish though.
(In reply to Albert Vaca from comment #15) > I wanted to do it last week, but I didn't find the time. It should happen > soonish though. Any chance of a release with the fix soon?
So with sshfs 3.2.0-1 it works correctly? Or do we have to wait till 3.2.1? Oh wait, I can test it ;). I managed to send some mp3 music file with right-click option "send to" and mp3 is fine, no corruption. So on Arch systems it all should be fine now.
(In reply to Michał Dybczak from comment #17) > So with sshfs 3.2.0-1 it works correctly? Or do we have to wait till 3.2.1? > > Oh wait, I can test it ;). > > I managed to send some mp3 music file with right-click option "send to" and > mp3 is fine, no corruption. So on Arch systems it all should be fine now. Can you try using the filesystem browser to copy/paste the file? If I recall correctly, the 'right click>send to' option has always worked without corruption. The corruption only occurred if one used the filesystem browser to copy/paste the file. If I understand correctly, the transfer was disabled on the Android side for large files, as a temporary workaround, and the actual fix is to change the mount options kdeconnect uses (See cpmments 12 and 13). As of now, the 'send a file option' works for me too, but the large file transfer via sshfs is still disabled. Hence I was wondering if a desktop release with the fix is planned soon.
You're right. When using Dolphin and dragging a file between panels/locations, it shows "cannot write /path1 to /path2". When I used a small text file, everything went ok. So I guess, we're still waiting for sshfs 3.2.1