Bug 314451 - sftp: Resuming partly transferred file >= 2 GiB is impossible - "unknown error code 166"
Summary: sftp: Resuming partly transferred file >= 2 GiB is impossible - "unknown erro...
Status: RESOLVED FIXED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: SFTP (other bugs)
Version First Reported In: 18.04.3
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Andreas Schneider
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-05 11:28 UTC by andros
Modified: 2018-09-24 12:28 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
KIO error log (82.88 KB, text/plain)
2015-01-26 15:39 UTC, Jeffrey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andros 2013-02-05 11:28:55 UTC
I have tried to copy a big file (3.6GB) via sftp with Dolphin. 

After a few hours my line disconnects for a second and after that the transfer stopped with a message that gives me only three options: 
"ignore", "ignore all", "Cancel"

I have cancel because i wanted to resume the upload.

The window with the remote site (sftp) was open and seemed to be connected, again.
But when i tried to copy the file again,to resume it, i got this message:

"unknown error code 166"

So i closed all dolphin windows and restart one window and reconnect to the sftp host again.

The *.part file is visible on the server side.
But when i try to copy the same file again to resume the transfer, it gives only the same messages as before (error code 166).

If i try to upload an other file it works.

When dolphins is started in the console i get this output when i try to resume the file:

""/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAMEnepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
dolphin(2081) KXMLGUI::ActionList::plug: Index  25  is not within range (0 -  13 
dolphin(2081) KSambaSharePrivate::testparmParamValue: Running testparm ("-d0", "-s", "--parameter-name", "usershare path")
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Invalid iterator."
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAMEnepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Invalid iterator."
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Could not connect to server at /tmp/ksocket-MYUSERNAME/nepomuk-socket (No such file or directory)"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Unsupported operation (2)": "Invalid model"
"/usr/bin/dolphin(2081)" Soprano: "Invalid iterator."
QProcess: Destroyed while process is still running.
dolphin(2081) KSharedUiServerProxy::KSharedUiServerProxy: kuiserver registered"

On the server side i get this messages in the moment when i try to copy this file:

SSH: Server;Ltype: Version;Remote: ***.***.***.***-58574;Protocol: 2.0;Client: libssh-0.5.2
Feb  5 12:02:04 localhost sshd[30960]: SSH: Server;Ltype: Kex;Remote: ***.***.***.***-58574;Enc: aes256-ctr;MAC: hmac-sha1;Comp: none [preauth]
Feb  5 12:02:04 localhost sshd[30960]: SSH: Server;Ltype: Authname;Remote: ***.***.***.***-58574;Name: MYUSERNAME [preauth]
Feb  5 12:02:04 localhost sshd[30960]: Accepted publickey for MYUSERNAME from ***.***.***.*** port 58574 ssh2
Feb  5 12:02:04 localhost sshd[30960]: pam_unix(sshd:session): session opened for user MYUSERNAME by (uid=0)
Feb  5 12:02:04 localhost sshd[30962]: subsystem request for sftp by user MYUSERNAME


System information:
uname -a 

dolphin -v
Qt: 4.8.4
KDE Development Platform: 4.9.5
Dolphin: 2.1

uname -a
Linux host 3.7.4-gentoo #1 SMP Tue Jan 29 12:54:44 CET 2013 x86_64 AMD A8-3500M APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux

Dolphin installed Version from package manager:
kde-base/dolphin
     Installed versions:  4.9.5(4)^t(02:53:10 07.01.2013)(handbook semantic-desktop thumbnail -aqua -debug)












Reproducible: Always

Steps to Reproduce:
1. Connect Dolphin to an sftp:// address.
2. Copy a file from our local folder to the remote folder.
3. When the internet connection was disconnected, try to resume the partly uploaded file.
Actual Results:  
error code 166

Expected Results:  
resuming and finishing the upload
Comment 1 Frank Reininghaus 2013-02-05 16:40:17 UTC
Thanks for the bug report! Reassigning to the sftp kioslave.
Comment 2 andros 2013-02-06 10:22:36 UTC
I have to add that i can't reproduce this always. Today i have tested a disconnect with two files and they were resumed and finished after that successfully.

So i have to say i don't know how to reproduce this behaviour at all.

Maybe it's because of the file size ? The file was 3.6GB and it break up on 2.4 GB.
Comment 3 Dawit Alemayehu 2013-11-21 13:18:59 UTC
(In reply to comment #2)
> I have to add that i can't reproduce this always. Today i have tested a
> disconnect with two files and they were resumed and finished after that
> successfully.
> 
> So i have to say i don't know how to reproduce this behaviour at all.
> 
> Maybe it's because of the file size ? The file was 3.6GB and it break up on
> 2.4 GB.

File size should not have any influence on this matter. Also I tried to reproduce this with a large ISO file and could not. Can you try it again with a large file and see if you can reproduce it?
Comment 4 Jeffrey 2015-01-23 21:49:52 UTC
I also have this issue, running KDE 4.14.2 and Dolphin 4.14.2 on Debian Testing, copying to an SFTP server over KIO-SFTP.

The KIO seems to drop out after 1022MB and I have to restart/resume the copy after every 1022MB, but after the file reaches 3GB I can no longer resume this cope and I get the "Unknown Error Code 166" which asks that I submit a full bug report for this unknown error.

Running Dolphin from the command line doesn't have any further output when the error happens.
Comment 5 Andreas Schneider 2015-01-26 08:51:39 UTC
Can you try to create a log file? To which SSH server are you copying too?

https://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_sftp
Comment 6 Jeffrey 2015-01-26 15:39:17 UTC
Created attachment 90670 [details]
KIO error log

(Version info below far below; error log attached)

What I do is open Dolphin on my Debian 8 desktop and within Dolphin, I open a SFTP connection to a remote FreeBSD 10 server and start copying the file.  After the FreeBSD server side receives 1071759360 bytes, the KIO stops moving and transfer speed drops to zero (but the KDE Information popup doesn't say it's completed, it just spins)
# ls -la
-rw-r--r--    1 root  wheel  1071759360 Jan 26 09:03 takeout_gmail_2files.tar.gz.part

After I restart it, the copy operation resumes until KIO stops a second time, and the remote file is:
# ls -la
-rw-r--r--    1 root  wheel  2144133120 Jan 26 09:27 takeout_gmail_2files.tar.gz.part

I then restart the copy process a third time; it resumes and dies again after the remote file is
# ls -la
-rw-r--r--    1 root  wheel  3215953920 Jan 26 09:31 takeout_gmail_2files.tar.gz.part

After that 3rd process fails, I then try a 4th time and get the error:
"
Unknown error code 166
/home/myusername/Downloads/takeout_gmail_2files.tar.gz
Please send a full bug report at http://bugs.kde.org.
"

I've attached the KIO error log as you had requested; I don't know where any libssh debugging went to:
$ KIO_SFTP_LOG_VERBOSITY=1 kdeinit4
kdeinit4: Shutting down running client.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
KDE Daemon (kded) already running.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
kbuildsycoca4 running...
kbuildsycoca4(20654) VFolderMenu::loadDoc: Parse error in  "/home/myusername/.config/menus/applications-merged/xdg-desktop-menu-dummy.menu" , line  1 , col  1 :  "unexpected end of file" 


Server side:
FreeBSD 10.1-RELEASE
OpenSSH_6.6.1p1, OpenSSL 1.0.1j-freebsd 15 Oct 2014

Client/Desktop side:
Debian 8.0 (Debian testing)
$ apt-cache policy libssh* | grep -B1  "Installed"
libsslcommon2-dev:
  Installed: (none)
--
libsss-idmap-dev:
  Installed: (none)
--
libsscm-dev:
  Installed: (none)
--
libssreflect-ocaml-32ks0:
  Installed: (none)
--
libsss-sudo:
  Installed: (none)
--
libssh-doc:
  Installed: (none)
--
libssl1.0.0:
  Installed: 1.0.1k-1
--
libss7-1:
  Installed: (none)
--
libssl0.9.8-dbg:
  Installed: (none)
--
libssreflect-coq:
  Installed: (none)
--
libssl0.9.8:
  Installed: (none)
--
python-libsss-nss-idmap:
  Installed: (none)
--
libssl1.0.0-dbg:
  Installed: (none)
--
libssh2-php:
  Installed: (none)
--
libsss-nss-idmap-dev:
  Installed: (none)
--
libssh2-1-dbg:
  Installed: (none)
--
libssh2-1-dev:
  Installed: (none)
--
libsss-idmap0:
  Installed: (none)
--
libss2:
  Installed: 1.42.12-1
--
python2.7-libssh2:
  Installed: (none)
--
libssh-4:
  Installed: 0.6.3-3+b1
--
libssh-2-dev:
  Installed: (none)
--
libsslcommon2:
  Installed: (none)
--
libsss-sudo-dev:
  Installed: (none)
--
libssl-ocaml-w5np0:
  Installed: (none)
--
libsss-nss-idmap0:
  Installed: (none)
--
libssh2-1:
  Installed: 1.4.3-4
--
libssl-ocaml:
  Installed: (none)
--
libssh-gcrypt-4:
  Installed: 0.6.3-3+b1
--
libssl-dev:
  Installed: (none)
--
libss7-dbg:
  Installed: (none)
--
libssh-2-doc:
  Installed: (none)
--
libsscm3:
  Installed: (none)
--
libssreflect-ocaml-dev:
  Installed: (none)
--
libss7-dev:
  Installed: (none)
--
python-libssh2:
  Installed: (none)
--
libss2-dbg:
  Installed: (none)
--
libssm-dev:
  Installed: (none)
--
libssl-doc:
  Installed: (none)
--
libssh-gcrypt-dev:
  Installed: (none)
--
libssreflect-ocaml:
  Installed: (none)
--
libssh-dbg:
  Installed: (none)
--
libssm1-dbg:
  Installed: (none)
--
libssl-ocaml-dev-w5np0:
  Installed: (none)
--
libssh-dev:
  Installed: (none)
--
python2.6-libssh2:
  Installed: (none)
--
libssl-ocaml-dev:
  Installed: (none)
--
libssm1:
  Installed: (none)
--
libssreflect-ocaml-dev-32ks0:
  Installed: (none)
Comment 7 Jeffrey 2016-09-28 17:55:07 UTC
This is still an issue with Debian 9 (Stretch) running KDE 5.25.0 and Dolphin 16.04.2. This bug report is over 3.5 years old and network file operations are still not working well.

Copying a file across KIO in Dolphin (to sftp://10.10.11.150:/root/users/ if it matters) still only partially copies the file. KDE now notifies that the copy is complete (it didn't notify before), but that message is not correct and the remote machine still only gets 1071882240 bytes and then KDE says the copy is complete.

Resuming that copy operation once brings the remote-server's filesize total to 2143764480 before KDE notifies incorrectly that this is done.

Resuming the copy operation a second time brings the remote total to 3215585280 bytes.

Trying to resume a third time, Dolphin presents this error:
> Unknown error code 166
> /home/jthomas/Downloads/bigfile.tar.gz
> Please send a full bug report at http://bugs.kde.org.
> [Retry] [Cancel]

The [Retry] button just has this same error dialog box reappear.
Comment 8 Kevin Kofler 2016-10-31 13:03:53 UTC
This still happens with current KDE 4 versions of kio_sftp. (The KF5 version may or may not be also affected.) At least, I had this moving files from a Fedora 21 source to a Fedora 24 destination with Krusader (kdelibs 4 version).

The important part that is missing in the subject is that it only happens on files which do not fit in a 32-bit int. I never had this happen with any other file. I had it happen with a > 4 GiB file. The OP's was 3.6 GiB, so I guess the limit is probably the signed 32-bit int, so 2 GiB - 1 byte.

The funny thing is that both source and destination machines are x86_64 and use 64-bit kio_sftp. So lack of large file support cannot be the issue. I guess the resume offset is stored in an int somehow.

When moving the file from the source (local source, SFTP remote destination), I had exactly the behavior described here: the unknown numeric error code.

I then tried to SFTP the remainder of the file the other way, running Krusader on the destination instead (SFTP remote source, local destination), and the result was even worse: It resumed, but the resume offset was truncated (as was visible immediately from the progress report)! As a result, it redownloaded parts that I already had in my .part file, corrupting the output file! So the whole hour I had spent transferring the first > 5 GiB until it broke down was wasted.
Comment 9 Andreas Schneider 2016-11-07 08:44:14 UTC
When we append, sftpProtocol::seek(KIO::filesize_t offset) is called, this calls sftp_seek64(). sftp uses 64bit values internally.

Can you turn on debugging:

https://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_sftp

The seek function prints the offset KDE uses ...

It prints: seek, offset = xxx

If this is the correct value it is an issue in libssh. However the libssh code seems to be correct. The only issue could be our htonll() function. I implemented a simpler version in the meantime.

You can try the v0-7 branch of libssh if you want. It will be released as 0.7.4 soon.
Comment 10 Andreas Schneider 2018-09-24 12:28:12 UTC
Fixed with libssh 0.8

https://www.libssh.org/2018/09/21/libssh-0-8-3/