SUMMARY Using file copy (F5) from local disk to remote SFTP folder is resulting to file, which is then copied as X.jpg.part instead of X.jpg - auto rename after copy is not done. Content of the file is OK. This is also affecting direct editing of the files on the server using editor, because it's not uploading edited file correctly. STEPS TO REPRODUCE 1. copy local file to remote server using SFTP 2. refresh remote folder and search for the file 3. file is created as .part only OBSERVED RESULT File copying is not finished properly. EXPECTED RESULT File should be renamed back to original name after copy. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Using Gnome 3 (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: not found in RPMs (?) Qt Version: 5.13 ADDITIONAL INFORMATION Let me know if anything else is needed. Thanks.
Can you try with Dolphin? It's seems to be related with KIO extras (the package that provides sftp connections to KDE).
(In reply to Davide Gianforte from comment #1) > Can you try with Dolphin? It's seems to be related with KIO extras (the > package that provides sftp connections to KDE). I can confirm very same behaviour in Dolphin, so issue will be in underlying library, as you wrote. Coud you please direct me to the right bug tracker? Thank you. Ivan
Confirmed by OP both on Krusader and Dolphin
What's the remote server software used and what version etc? Any special configuration? Please run dolphin with QT_LOGGING_RULES="KIO_SFTP_LOG=true;KIO_SFTP_TRACE_LOG=true" dolphin --new-window and reproduce the issue, then attach the output to this bug report.
Server software is ProFTPd v 1.3.6 I ran Dophin with mentioned setup (command) and reproduced issue, but I can't find any log or trace or what is really expected. Is there any special location where such logs are written, please?
The output ought to be on stdout, but then I suppose it may also not be there depending on how the source was built. In any event what would also be cool is the exact proftpd config to reproduce this with. There is very similar bug report that also has to do with proftpd but unfortunately I couldn't reproduce it with a cobbled together proftd-sftp setup.
Here it is: <IfModule mod_sftp.c> <VirtualHost 0.0.0.0> SFTPEngine on Port 22 SFTPHostKey /etc/ssh/ssh_host_ecdsa_key SFTPCiphers aes256-ctr aes192-ctr aes128-ctr SFTPDigests hmac-sha2-512 hmac-sha2-256 # ecdh-sha2-nistp256 je tam kvoli libssh SFTPKeyExchanges diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 SFTPCompression delayed MaxLoginAttempts 6 </VirtualHost> </IfModule>
We just confirmed that it works with version 19.04. And as far as I remember, it really stopped working couple of months ago with some update.
Awesome! I can reproduce the problem now. By the looks of it this is a bug in proftpd though. It falls over zero byte writes.
*** Bug 418472 has been marked as a duplicate of this bug. ***
Git commit effb511c5b95ef14b5eca4ad982f98ac213890e3 by Harald Sitter. Committed on 29/04/2020 at 13:25. Pushed by sitter into branch 'master'. sftp: successfully write files to proftpd servers proftpd doesn't like zero size writes and returns with an error leading us to assume that the write failed, when in fact it was fine eitherway because we didn't write anything one way or the other. so, instead just break out of the loop early. there's nothing lost by us not doing that final EOF write since we don't need it from a protocol POV. the break occurs just before writing because preceding it is "spin-up" tech opening the file and so forth. we need to have that run even when putting a 0b file. this successfully writes 0B, 1B, and 128M files both with partial markers enabled and disabled to proftpd 1.3.6c FIXED-IN: 20.04.1 M +11 -0 sftp/kio_sftp.cpp https://commits.kde.org/kio-extras/effb511c5b95ef14b5eca4ad982f98ac213890e3
Thank you very much! I'll test the package once is available in Fedora repo.