https://bugs.kde.org/show_bug.cgi?id=314451
Kevin Kofler <kevin.kof...@chello.at> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WAITINGFORINFO |---
Summary|sftp: Resuming partly |sftp: Resuming partly
|transferred file is |transferred file >= 2 GiB
|impossible - "unknown error |is impossible - "unknown
|code 166" |error code 166"
Ever confirmed|0 |1
CC| |kevin.kof...@chello.at
Status|NEEDSINFO |CONFIRMED
--- Comment #8 from Kevin Kofler <kevin.kof...@chello.at> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
