This is not a bug, but an enhancement. I would like to see the command-line sftp have the ability to resume interrupted downloads/ uploads. If there's a reason why sftp-resume will not be implemented, a FAQ entry would be appreciated.
resume would be a nice feature for sftp and the protocol generally supports it. It just takes someone to write the code and make a patch (I don't have time). There may be some subtlety if the server reorders the blocks it has sent back to the client when the original transfer was aborted. E.g. the client requests 5 contiguous blocks of 64k from the start of the file and the server sends back blocks 1, 2, and 5. If the client wrote block 5 to disk, the the file would appear to be the full length but wouldn't contain all the data. We would need to modify the download and upload routines to ftruncate() at the highest contiguous point transferred. This should probably be done anyway...
Created attachment 889 [details] Implement truncation at "high water mark" on error This patch does the clean truncation part. It is only useful for downloads.
Isn't this fixed in 6.3? * sftp(1): add support for resuming partial downloads using the "reget" command and on the sftp commandline or on the "get" commandline using the "-a" (append) option.
Yes, resumption is implemented for both get and put now.
Close all resolved bugs after 7.3p1 release