Created attachment 119017 [details]
left: file pulled with adb; right: file transfered with SFTP

The SFTP protocol is a slow protocol. Are you sure the copy process was complete before you try to open the image? I get the same behavior when I try to directly open images (jpg, png or raw's) on the phone's storage. Some programs handle the slow transfer speed well others don't

(In reply to Erik Duisters from comment #2)
> The SFTP protocol is a slow protocol. Are you sure the copy process was
> complete before you try to open the image? I get the same behavior when I
> try to directly open images (jpg, png or raw's) on the phone's storage. Some
> programs handle the slow transfer speed well others don't

I can confirm the copy is complete. I also tried with multiple images. The corrupt files have altered content rather than being incomplete.

However, I failed to reproduce the problem on another computer (under the same network), which is really weird. I suppose only bugs in sftp or the Android app can cause such behavior. Will do more test to tell what is going on.

(In reply to zhangchi866 from comment #3)
> (In reply to Erik Duisters from comment #2)
> > The SFTP protocol is a slow protocol. Are you sure the copy process was
> > complete before you try to open the image? I get the same behavior when I
> > try to directly open images (jpg, png or raw's) on the phone's storage. Some
> > programs handle the slow transfer speed well others don't
> 
> I can confirm the copy is complete. I also tried with multiple images. The
> corrupt files have altered content rather than being incomplete.
> 
> However, I failed to reproduce the problem on another computer (under the
> same network), which is really weird. I suppose only bugs in sftp or the
> Android app can cause such behavior. Will do more test to tell what is going
> on.

Actually, just retried on the other computer and the problem emerges, although slightly different (corruption starts at different addresses, did 2 run, between which I killed kdeconnectd on my computer, and got 0x00008000 & 0x0001c000, respectively). I have no idea why it worked as intended in the first try.

By my understanding, kdeconnect is using system's sshfs program and that should be quite reliable, is it?

Please see the previous comments

I can confirm that files get corrupted quite often during transfer with Android app v1.12.6.

I already lost a mp4 video file and some jpgs.

Same config as above: Debian testing (kdeconnect desktop v1.3.3) and Android app v1.12.6 (f-droid). This issue doesn't happen at all with former last working version v1.10.1: the transfer can be slow, but I never got anything corrupted with that version.

I also see the same bug: JPEG, mp4 and PDF files corrupted almost always (I would say probability to get a corrupted file is about 80%)

KDE Neon User latest
Android app v1.12.6  (I've tried to install from Google Play and from F-Droid: the same bug)
KDE connect app: 1.3.4-0xneon+18.04+bionic+build11
sshfs: 3.2

Probably it could be related to https://bugs.kde.org/show_bug.cgi?id=383069 and -o writeback_cache=no

I didn't see this issue with previous kdeconnect version

Sorry I was wrong about sshfs version (and I don't see how to modify my previous comment). It's 2.8-1

I've started noticing problems with this today, doesn't happen with smaller files although I just tried opening a 70 kB xlsx file and that wouldn't work. Small jpgs and pdfs seem to be OK, but anything else breaks.

(In reply to Yuriy Vidineev from comment #7)
> [...]
> sshfs: 3.2
> 
> Probably it could be related to https://bugs.kde.org/show_bug.cgi?id=383069
> and -o writeback_cache=no
> 
> I didn't see this issue with previous kdeconnect version

Can this issue be related to sshfs if downgrading the Android app solves it?
Downgraded app to v1.10.1, no issues at all as always.

sshfs v2.10 here (Debian Buster), anyways.

Mau, I didn't know that downgrade of Android app helped. In that case probably it's not sshfs issue. But where have you got 1.10 version? I want to try it as well

(In reply to Yuriy Vidineev from comment #11)
> Mau, I didn't know that downgrade of Android app helped. In that case
> probably it's not sshfs issue. But where have you got 1.10 version? I want
> to try it as well

F-Droid (by installing the app more old versions will be available; please note that, by my experience, the first somewhat working after 1.10.1 is 1.12.6):

https://f-droid.org/en/packages/org.kde.kdeconnect_tp/

Let us know your findings, thanks

Thanks, Mau.
But oldest available version on F-Droid that I see is 
Version 1.12 (11200) - Added on 2019-03-10

It doesn't show 1.10.1 even in a F-Droid app
I'll try to search other sources for 1.10

(In reply to Yuriy Vidineev from comment #13)
> Thanks, Mau.
> But oldest available version on F-Droid that I see is 
> Version 1.12 (11200) - Added on 2019-03-10
> 
> It doesn't show 1.10.1 even in a F-Droid app
> I'll try to search other sources for 1.10

Sorry Yuriy, I forgot to mention you have to enable the "F-Droid Archive" repository.

Thanks, Mau!
KDE Connect 1.10.1 android app works like a charm for me.
I use Samsung Galaxy Note 8 with Android 9, and kdeconnect         1.3.4-0xneon+18.04+bionic+build11 on a laptop

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

With 
Android App 1.12.7  (NOTE 1.10.1 works fine!)
Ubuntu 19.04
kdeconnect:1.3.4-ubuntu1

SSHFS version 2.10.0
FUSE library version: 2.9.9
fusermount version: 2.9.9
using FUSE kernel interface version 7.19

Every copy of a file from the device produces a corrupted result.
Very small files seem to arrive ok, all others are broken 100% of the tries.

I tried Android app version 1.10.1, which didn't show the bug!

First difference is at byte 65537, for all files I tried. Looks like a 16bit boundary?
cmp  20190611_085406.mp4 ../20190611_085406.mp4                                                   
20190611_085406.mp4 ../20190611_085406.mp4 differ: byte 65537, line 251

For reference: All bigger files have a different md5sum, videos are unplayable.
On the receiving PC:

7368496469963234c5b86fd7b7a2bd46  20190602_153915.mp4
df49314e4b3084800b2f8c786cdf7818  20190602_154111.mp4
cc712b962f942df17bba1ee98cced7ea  20190602_155005_002_1.mp4
4233f29b9d16184658be72ca5fad2698  20190602_155005_002.mp4
8b95f9e455e4e1aeef6214eed03905fa  20190602_155005.mp4
9b619c2d6f06993e633c303b47940482  20190602_160200.mp4
d7bbd3f3d4c08d0d7e95b7b4a8c2e01c  20190609_123102.jpg
05619c2e4aec628f10b677eeff5d2da6  20190609_131844.jpg
7096ae70b2cc5077e0c22900ad8e958e  20190609_131946.jpg
cff2e82d0dba3ad0d8a0a9cdd6ee264e  20190609_134142.jpg
5fd673e249844f5bc098d34d4ba2f7ad  20190611_085355.mp4
29928a9c678194035925483c193476bf  20190611_085406.mp4

-rw-rw-rw- 1 flo flo 102637754 Jun  2 15:42 20190602_153915.mp4
-rw-rw-rw- 1 flo flo  21902289 Jun  2 15:41 20190602_154111.mp4
-rw-rw-rw- 1 flo flo   7840006 Jun 11 08:48 20190602_155005_002_1.mp4
-rw-rw-rw- 1 flo flo  13277710 Jun 11 08:46 20190602_155005_002.mp4
-rw-rw-rw- 1 flo flo  19312877 Jun 11 08:46 20190602_155005.mp4
-rw-rw-rw- 1 flo flo  30747096 Jun  2 16:02 20190602_160200.mp4
-rw-rw-rw- 1 flo flo   1969455 Jun  9 12:31 20190609_123102.jpg
-rw-rw-rw- 1 flo flo   2805541 Jun  9 13:18 20190609_131844.jpg
-rw-rw-rw- 1 flo flo   1311053 Jun  9 13:19 20190609_131946.jpg
-rw-rw-rw- 1 flo flo   2506547 Jun  9 13:41 20190609_134142.jpg
-rw-rw-rw- 1 flo flo   2863015 Jun 11 08:54 20190611_085355.mp4
-rw-rw-rw- 1 flo flo  24200139 Jun 11 08:54 20190611_085406.mp4

adb shell on android

1c93986f545424e393d8d9fc40b329c5  20190602_153915.mp4
7031c6f1550bb365c5095cc4e033b470  20190602_154111.mp4
8dfa45e00b65c343be21f989e4facfd5  20190602_155005_002_1.mp4
e93daf56fb252a9743681c4cd644a878  20190602_155005_002.mp4
61b8d30af508cc9fb6492e959c794bb3  20190602_155005.mp4
55f20b6598996b7090765da0e9bc6033  20190602_160200.mp4
d7bbd3f3d4c08d0d7e95b7b4a8c2e01c  20190609_123102.jpg
05619c2e4aec628f10b677eeff5d2da6  20190609_131844.jpg
7096ae70b2cc5077e0c22900ad8e958e  20190609_131946.jpg
cff2e82d0dba3ad0d8a0a9cdd6ee264e  20190609_134142.jpg
29a39f692db839633decbe1ec261a6c7  20190611_085355.mp4
6e2b5ab3332097c06e446c6593b6d1ff  20190611_085406.mp4
-rw-rw---- 1 root sdcard_rw 102637754 2019-06-02 15:42 20190602_153915.mp4
-rw-rw---- 1 root sdcard_rw  21902289 2019-06-02 15:41 20190602_154111.mp4
-rw-rw---- 1 root sdcard_rw   7840006 2019-06-11 08:48 20190602_155005_002_1.mp4
-rw-rw---- 1 root sdcard_rw  13277710 2019-06-11 08:46 20190602_155005_002.mp4
-rw-rw---- 1 root sdcard_rw  19312877 2019-06-11 08:46 20190602_155005.mp4
-rw-rw---- 1 root sdcard_rw  30747096 2019-06-02 16:02 20190602_160200.mp4
-rw-rw---- 1 root sdcard_rw   1969455 2019-06-09 12:31 20190609_123102.jpg
-rw-rw---- 1 root sdcard_rw   2805541 2019-06-09 13:18 20190609_131844.jpg
-rw-rw---- 1 root sdcard_rw   1311053 2019-06-09 13:19 20190609_131946.jpg
-rw-rw---- 1 root sdcard_rw   2506547 2019-06-09 13:41 20190609_134142.jpg
-rw-rw---- 1 root sdcard_rw   2863015 2019-06-11 08:54 20190611_085355.mp4
-rw-rw---- 1 root sdcard_rw  24200139 2019-06-11 08:54 20190611_085406.mp4

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

Hi, just wanted to add, that I can no longer reproduce this issue.
Android app version is 1.12.93.
Several tries showed identical file hashes.
Was it fixed?

Just tested it now, I am unable to reproduce this issue also on 1.12.93. I also had errors like "Unable to transfer file", but they don't appear now. Seems that it's fixed.

I still has the same issue with 1.12.93 (Android 9, Samsung Galaxy Note 8) and kdeconnect 1.3.5-0xneon+18.04+bionic+build21 (latest KDE Neon). MD5 sums are different, there are errors when opening JPEG files


Corrupt JPEG data: premature end of data segment
Invalid JPEG file structure: two SOI markers

I experience the same problem when copying GPX files (clear text XML format) that I have recorded with my GPS.

When copying the .gpx files from phone to Linux desktop (KDE Neon) the files become corrupt.

Small note: I see file corruption when copy from phone to PC, but I never saw corrupted files when copy from PC to a phone

(In reply to Yuriy Vidineev from comment #23)
> Small note: I see file corruption when copy from phone to PC, but I never
> saw corrupted files when copy from PC to a phone

i confirm this.

also no problem with Bluetooth.

(In reply to Philippe ROUBACH from comment #24)

> also no problem with Bluetooth.

android + Astro bluetooth (obex ftp)

openSuse Argon 15.1
Samsung S2 Plus, lineage os (android 7.1.2)

kde apps 19.04.3
kde plasma 5.16.3
kde frameworks 5.60.0
kde qt 5.13.0

kdeconnect android 1.12.93
kdeconnect kde 1.3.5

I copy five jpg files from phone to pc without any problem.

openSuse Argon 15.1
Samsung S7, android 8.0

kde apps 19.04.3
kde plasma 5.16.3
kde frameworks 5.60.0
kde qt 5.13.0

kdeconnect android 1.12.93
kdeconnect kde 1.3.5

I copy six jpg files from phone to pc => three corrupt jpg files.

what is the difference between lineage os 14.1 (<=> android 7.1.2) and Samsung android 8.0 ?

this is the second time i check that lineage os works better with kdeconnect.

(In reply to Philippe ROUBACH from comment #27)
> I copy six jpg files from phone to pc => three corrupt jpg files.

If a JPEG file is corrupt, you might not always notice it. It's better to compare the whole file byte-by-byte. For example, transfer a file to your computer via KDE Connect and then the same file using another application, e.g. on Whatsapp or Telegram, or upload to Google Drive, or send it to yourself in an email. Then compare the two copies with "diff" command or by checking their MD5/SHA1 checksums.

I usually compare md5 sum on PC and Android (using HashDroid)

(In reply to Alexander Potashev from comment #28)
> (In reply to Philippe ROUBACH from comment #27)
> > I copy six jpg files from phone to pc => three corrupt jpg files.
> 
> If a JPEG file is corrupt, you might not always notice it. It's better to
> compare the whole file byte-by-byte. For example, transfer a file to your
> computer via KDE Connect and then the same file using another application,
> e.g. on Whatsapp or Telegram, or upload to Google Drive, or send it to
> yourself in an email. Then compare the two copies with "diff" command or by
> checking their MD5/SHA1 checksums.

In my case it's very simple to check corruption of jpg files. 
Dolphin cannot compute the preview and if i open it with gwenview then a part of the image is gray.

(In reply to Philippe ROUBACH from comment #30)
> In my case it's very simple to check corruption of jpg files. 
> Dolphin cannot compute the preview and if i open it with gwenview then a
> part of the image is gray.

I have exactly the same effects

(In reply to Philippe ROUBACH from comment #26)
> openSuse Argon 15.1
> Samsung S2 Plus, lineage os (android 7.1.2)
> 
> kde apps 19.04.3
> kde plasma 5.16.3
> kde frameworks 5.60.0
> kde qt 5.13.0
> 
> kdeconnect android 1.12.93
> kdeconnect kde 1.3.5
> 
> I copy five jpg files from phone to pc without any problem.

i made an error.

files are corrupted but it is not visible. files have a "libpng error: IDAT: CRC error"

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

I tried copying 200 JPEGs from phone to laptop over KDE Connect and could not reproduce this, SHA-1 checksums for all files are identical.

kdeconnect android 1.12.93
kdeconnect kde 1.3.3

Operating System: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4
Kernel Version: 5.1.16-300.fc30.x86_64
OS Type: 64-bit
Processors: 2 × Intel® Celeron® CPU B800 @ 1.50GHz
Memory: 3,8 ГиБ

Phone: Xiaomi Mi A1
OS: Android 9.0

*** This bug has been confirmed by popular vote. ***

(In reply to Alexander Potashev from comment #34)
> I tried copying 200 JPEGs from phone to laptop over KDE Connect and could
> not reproduce this, SHA-1 checksums for all files are identical.
> 
> kdeconnect android 1.12.93
> kdeconnect kde 1.3.3
> 
> Operating System: Fedora 30
> KDE Plasma Version: 5.15.5
> KDE Frameworks Version: 5.59.0
> Qt Version: 5.12.4
> Kernel Version: 5.1.16-300.fc30.x86_64
> OS Type: 64-bit
> Processors: 2 × Intel® Celeron® CPU B800 @ 1.50GHz
> Memory: 3,8 ГиБ
> 
> Phone: Xiaomi Mi A1
> OS: Android 9.0

Tried again just now with kdeconnect android 1.13. For me, all the JPEG files are intact (verified with `sha1sum` in `adb shell` and Dolphin), but DNG files are still corrupt.

It could have something to do with the file size. My JPEGs top at 7.6 MB, while the DNG files are 22.1 MB each.

Similarly for my current configuration:

Android side:
Android 8.0.0
kdeconnect android 1.13
Phone: ASUS ZenFone 4 Pro (Z01GD)

Desktop side:
kdeconnect kde 1.3.3
SSHFS version 2.10.0
FUSE library version: 2.9.9
fusermount version: 2.9.9
using FUSE kernel interface version 7.19
Operating System: Debian testing 
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54.0
Qt Version: 5.11.3
Kernel Version: 4.19.0-5-amd64
OS Type: 64-bit
Processors: Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz
Memory: 15839.1 MB total

I still have issue with corrupted JPEG on kdeconnect android 1.13.2 and 1.3.5-0xneon+18.04+bionic+build21 desktop app

(In reply to Yuriy Vidineev from comment #37)
> I still have issue with corrupted JPEG on kdeconnect android 1.13.2 and
> 1.3.5-0xneon+18.04+bionic+build21 desktop app

Same here 1.3.5-0ubuntu1~ubuntu19.04~ppa1 and 1.13.2, tried to copy a 2.9MB JPEG from phone to computer and it is corrupted.

Let's vote this bug in order to rise severity. I'm not updating since v1.10.1.

Same problem here of corrupted mp4 files copied via Dolphin (Kubuntu).

(In reply to ian from comment #40)
> Same problem here of corrupted mp4 files copied via Dolphin (Kubuntu).

What versions of KDE Connect do you use?

(In reply to Alexander Potashev from comment #41)
> (In reply to ian from comment #40)
> > Same problem here of corrupted mp4 files copied via Dolphin (Kubuntu).
> 
> What versions of KDE Connect do you use?

Same problem in Kubuntu 18.04 and 19.04 with KDE Connect for Android 9 latest version. The only one that works is the 1.10.1 (as mentioned in the comments) but I didn't try those just after of before this one. Also I only tried the most recent versions from Play Store.

Same issue here. It works with 1.11, but the moment i switch to 1.12 it breaks. Using 1.3.5 on openSUSE linux leap 15.1.

Not sure whether it is related but since 1.12 you need to define the storage locations manually where before it was done automatically with pre-defined names. 

Showing of the directory content in 1.11 and before is also much faster than from 1.12 onwards. 

Sending of files from phone to linux works fine even in the higher versions. 

Really would like the other way around working again as that makes it easier to copy large amounts of files from the phone to my main system through dolphin.

I just tried 1.13.5 but still issue. Switching back to 1.11 and it works fine.

I've updated to KDE connect 1.4-0xneon+18.04+bionic+build23 on laptop and 1.13.5 on a phone (Galaxy Note 8, stock Android 9) - still can easily reproduce it on files > 3Mb

I'm having the same issue. kdeconnect 1.4 on Arch Linux Plasma, and 1.13.5 on Pixel 2 XL.

kdeconnectd shows the following log lines while pulling files:

kdeconnect.plugin.sftp: stdout: "Warning: Permanently added '[192.168.xx.xx]:1741' (RSA) to the list of known hosts.\r\n"                                                                              
kdeconnect.plugin.sftp: stdout: "Corrupted MAC on input.\r\n"
kdeconnect.plugin.sftp: stdout: "ssh_dispatch_run_fatal: Connection to 192.168.xx.xx port 1741: message authentication code incorrect\r\n"                                                             
kdeconnect.plugin.sftp: stdout: "remote host has disconnected\n"                                                                                                                                       
kdeconnect.plugin.sftp: stdout: "Warning: Permanently added '[192.168.xx.xx]:1741' (RSA) to the list of known hosts.\r\n"                                                                              
kdeconnect.plugin.sftp: stdout: "Corrupted MAC on input.\r\n"            
kdeconnect.plugin.sftp: stdout: "ssh_dispatch_run_fatal: Connection to 192.168.xx.xx port 1741: message authentication code incorrect\r\n"                                                             
kdeconnect.plugin.sftp: stdout: "remote host has disconnected\n"
kdeconnect.plugin.sftp: stdout: "Warning: Permanently added '[192.168.xx.xx]:1741' (RSA) to the list of known hosts.\r\n"
kdeconnect.plugin.sftp: stdout: "Corrupted MAC on input.\r\nssh_dispatch_run_fatal: Connection to 192.168.xx.xx port 1741: message authentication code incorrect\r\n"
kdeconnect.plugin.sftp: stdout: "remote host has disconnected\n"

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

Looks like it depends on Android version. I've just checked on an older phone and it works like a charm!

Works:
Galaxy Note 3, Android 5.0
KDE Connect 1.13.5 from Google Play
KDE Connect 1.4-0xneon+18.04+bionic+build23  on laptop with KDE Neon

Doesn't work
Galaxy Note 10, Android 9
KDE Connect 1.13.5 from F-Droid
KDE Connect 1.4-0xneon+18.04+bionic+build23  on laptop with KDE Neon

I found the easiest way to provoke it is to enable the preview in dolphin and then open a folder with a ton of images. Dolphin will be busy for a while trying to generate previews and if you move around the mouse and hover above some images while the previews are still loading it will become even more busy because now it will also try to extract the exif data from the files to show in the side panel along with a larger preview image.

eventually there will be a bunch of images whose preview is missing. If you try to copy this file to the desktop it will be corrupted. You can cose dolphin or F5 multiple times, the same file will appear to stay in this corrupted state.

It is corrupted in the file system cache. If you drop caches and buffers and try to copy it again it will most likely succeed.

The only reliable way I have found to copy a folder with lots of files and avoiud corruption is to close dolphin, open a console, then 

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" 

to remove any corrupted file fragments left over in the caches and then copy the entire folder using cp -r or midnight commander in the console, that way it will not try to open more than one file at a time and then no corruption will happen.

I have observed this with two different PCs (Kubuntu 18.04 and Kubuntu 19.10) and the Android version 1.13.7 from Play Store. 

My phone identifies itself as Galaxy S7, Android 8.0.0

Still getting corrupted files using 1.4-0ubuntu2~ubuntu19.10~ppa1 and 1.13.6 on Samsung S10 with Android 10.

I have just transferred about 20 music and 2 videos from my phone to desktop using kdeconnect...all corrupted...sadly it was a move and not a copy.

If someone has any idea of how to recover those files, that would be very appreciated. 
 
I think people should really be made aware of this problem.

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.18.2
KDE Frameworks Version: 5.67.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-40-generic
KDEconnect: 1.4-0ubuntu2~ubuntu19.10~ppa1
Phone: Lenovo p2
Andrioid 9 (Lineage OS 16)
I had the same problem on android 7.

Sorry I realise I had forgotten to put the version of KDE Connect on my phone: it is 1.13.7

Is there a page where we should make this info more public to make users aware of the risk?

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

Confirmed for newer versions as well: 


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Ubuntu 19.10 with installed kubuntu-desktop and eaon kubuntu backports ppa
KDEConnect: 1.4.0 ubuntu from kubuntu backports
KDEConnect-Android: 1.14

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.18.3
KDE Frameworks Version: 5.67.0
Qt Version: 5.12.4
Kernel Version: 5.6.4-050604-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,5 GiB of RAM

(In reply to Gauthier from comment #51)
> Sorry I realise I had forgotten to put the version of KDE Connect on my
> phone: it is 1.13.7
> 
> Is there a page where we should make this info more public to make users
> aware of the risk?

I actually agree with you. I think there should be a warning on the kdeconnect page. I lost quite a few files because I used cut instead of copy in dolphin and realized too late they are all broken.

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

I can confirm the bug with KDE connect 1.14.2 on Android 9 and 1.3.3 on opensuse 15.1 when transferring gpx files from the phone to the desktop using dolphin on the desktop.
No corruption occurs when sending the files from the phone using KDE connect "Send files".
As the gpx files have a human readeable contents I observed the following:
1. The first 65536 bytes of the transferred file are correct.
2. From byte 65537 the contents starts over with the beginning of the original file
3. The rest of the file continues correctly but is cut at the end so that the file size remains the same as the original.

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

(In reply to kafe69 from comment #56)
> I can confirm the bug with KDE connect 1.14.2 on Android 9 and 1.3.3 on
> opensuse 15.1 when transferring gpx files from the phone to the desktop
> using dolphin on the desktop.
> No corruption occurs when sending the files from the phone using KDE connect
> "Send files".
> As the gpx files have a human readeable contents I observed the following:
> 1. The first 65536 bytes of the transferred file are correct.
> 2. From byte 65537 the contents starts over with the beginning of the
> original file
> 3. The rest of the file continues correctly but is cut at the end so that
> the file size remains the same as the original.

I can confirm this with KDE connect 1.15.1 on Android and 1.4-0ubuntu5 on Kubuntu.
The only difference I see is that the corruption starts after 32768 bytes.

Tested with a binary file created with:
import numpy as np
dat = np.arange(1000000)
dat.astype('int32').tofile("filename.bin")

and comparing "hexdump -C filename.bin" before and after transfer.

Pushing the same file from the phone to th PC with KDE connect works without corruption.

Just wondering, is anyone currently working on this issue (who has developer skills unlike me :))?

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

32k seems to be a magic number here, interesting.

A "problem" is that KDE Connect does not do the file operations itself but just delegates to sshfs on the desktop and an SFTP lib on Android, so I suspect the issue is in on of those. No idea currently which one though

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

(In reply to Nicolas Fella from comment #61)
> 32k seems to be a magic number here, interesting.
> 
> A "problem" is that KDE Connect does not do the file operations itself but
> just delegates to sshfs on the desktop and an SFTP lib on Android, so I
> suspect the issue is in on of those. No idea currently which one though

Is that true even in the case when the transfer is done through Dolphin? 

I'm asking because actually there is no corruption if the files are sent from the phone to desktop (by that I mean sending the file using share via KDEConnect on the phone). The corruption only occurs if the files are transferred from the phone to desktop using Dolphin.

(In reply to Gauthier from comment #63)
> (In reply to Nicolas Fella from comment #61)
> > 32k seems to be a magic number here, interesting.
> > 
> > A "problem" is that KDE Connect does not do the file operations itself but
> > just delegates to sshfs on the desktop and an SFTP lib on Android, so I
> > suspect the issue is in on of those. No idea currently which one though
> 
> Is that true even in the case when the transfer is done through Dolphin? 

Yes, sshfs mounts the phone content as a local file system and dolphin accesses that like a regular file

> 
> I'm asking because actually there is no corruption if the files are sent
> from the phone to desktop (by that I mean sending the file using share via
> KDEConnect on the phone). The corruption only occurs if the files are
> transferred from the phone to desktop using Dolphin.

The Share feature has a completely different implementation so it makes sense that it is not affected

(In reply to Nicolas Fella from comment #61)
> 32k seems to be a magic number here, interesting.
> 
> A "problem" is that KDE Connect does not do the file operations itself but
> just delegates to sshfs on the desktop and an SFTP lib on Android, so I
> suspect the issue is in on of those. No idea currently which one though

If this is the case, why do older versions work OK? 1.10.1 works fine, but anything newer than that corrupts files?

(In reply to Mark Fraser from comment #65)
> (In reply to Nicolas Fella from comment #61)
> > 32k seems to be a magic number here, interesting.
> > 
> > A "problem" is that KDE Connect does not do the file operations itself but
> > just delegates to sshfs on the desktop and an SFTP lib on Android, so I
> > suspect the issue is in on of those. No idea currently which one though
> 
> If this is the case, why do older versions work OK? 1.10.1 works fine, but
> anything newer than that corrupts files?

I just tried again and I can't reproduce the bug with 1.16.0
But looking at the comments in this bug and the duplicates there doesn't seem to be a consensus which versions are buggy.

Two ideas: 
Is there any way to get the credentials out of kdeconnect (either side) and connect to the phone with another sftp client?
Searching for sshfs and corrupted files leads to some issues which were related to cache. Nothing which sound related to this problem but maybe worth a try. Is there any way to manipulate the commandline options to sshfs to add "-o cache=no"?

I can confirm this bug, first 32k  bytes seems be repeated after 32767 position, then in some case seems to be a simple shift of 32k in other cases it starts in the same mode but then is much like a random corruption.

My configuration is:

PC:
Debian 10.9
kdeconnect 1.3.3-2 
sshfs 2.10+repack-2

Android Device:
Android 8.1.0
kdeconnect 1.16.0

On another device (an ebook reader with Android 4.0.4) the same kdeconnect app works, I cannot reproduce this bug.

If the file is sent from android to PC as a shared content no corruption is happen

I think that the kdeconnect application on Linux side could be only a frontend for sshfs, I can connect to my device (The smartphone with Android 8) with filezilla and I can't reproduce the problem, file are fetched without corruption

directories shared are mounted usually at /run/user/1000/{device id}
transfer using dolphin or cp produce the same result

if I mount the directory manually with sshfs the issue still happens

tips to trying a connection with filezilla:
- the connection between sshfs and the kdeconnect app happens with a ceretificate authentication, the username is "kdeconnect" 
- the private key is saved here ~/.config/kdeconnect/privateKey.pem
- for using this key for authentiation with filezilla you need to convert this in  an RSA key with
openssl rsa -in privateKey.pem -out privateRSAKey.pem
and then in a ppk key with
puttygen privateRSAKey.pem -o key.ppk
- the port used by kdeconnect app is 1739

not a great solution, but adding '-o direct_io' to the sshfs options solve the corruption issue

you can see the sshfs options used by kdeconnect with 
ps aux | grep sshfs

(In reply to Francesco from comment #68)
> not a great solution, but adding '-o direct_io' to the sshfs options solve
> the corruption issue
> 
> you can see the sshfs options used by kdeconnect with 
> ps aux | grep sshfs

Interesting find. Do you know what kind of other implications using direct_io might have?

I must partially retract my enthusiasm. With the direct_io option seems not completely usable.
It works if copy a file from sshfs to local with dolphin. 
Doesn't work if I open a PDF with okular on the remote folder or run a pdf2ps command on it.
Very strange, md5sum on the remote file generates a correct hash and a cat from remote to a local fetching a correct file 

Also with direct_io the tool vbindiff used to compare the remote file and a local copy show a strange behaviour: when scrolling the content the remote file is stop and doesn't leave firsts 32k bytes

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

(In reply to Nicolas Fella from comment #61)
> 32k seems to be a magic number here, interesting.
> 
> A "problem" is that KDE Connect does not do the file operations itself but
> just delegates to sshfs on the desktop and an SFTP lib on Android, so I
> suspect the issue is in on of those. No idea currently which one though

I also lost some files due to "move" instead of "copy" operation what pushed me here.

Alternative solution which I am using is to transfer files with "primitive ftpd" App which also has option to set up a SFTP server which I am manually mounting by sshfs with CMD:
`sshfs -o reconnect,sshfs_sync,ServerAliveInterval=15,ServerAliveCountMax=3,nonempty -C`

I am doing this since a year or even more and as far as I remember I have never received corrupted files.

Has anyone tried to bump the SSHD lib version on the Android side? It's missing 7 years worth of bugfixes from upstream. The version KDE Connect uses is around 2000 commits behind the latest master.

This problem exists since 2014-04-29 (my bug report https://bugs.kde.org/show_bug.cgi?id=334080). 6 years !

Where is the problem ?  Not enought man power, not enough knowledge, android problem ? what ?

For newer Android (> Kitkat), kdeconnect-android's SFTP implementation dose not support seeking to any non-current position.

It just ignores the offset and starts over the beginning of the file.

Here's the MR https://invent.kde.org/network/kdeconnect-android/-/merge_requests/275 for random reads.

(In reply to Nagy Tibor from comment #73)
> Has anyone tried to bump the SSHD lib version on the Android side? It's
> missing 7 years worth of bugfixes from upstream. The version KDE Connect
> uses is around 2000 commits behind the latest master.

We noticed that the sshd lib is outdated a couple of years ago. However upgrading turned out to be tricky since newer versions required specific Java APIs (in parcticular java.nio.*) that isn't available in older Android versions. That's why it wasn't updated. However by now things may have changes and/or it might be okay to drop support for those old versions, so the whole thing should be reevaluated

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

Fixed with https://invent.kde.org/network/kdeconnect-android/-/merge_requests/275