On Wed, 20 Feb 2008, mikep_at_proatria.com wrote:

> I've produced a simple patch

Thanks!

> largely based on the ftp resume code.

Yeah, one of these days we should probably refactor the resume stuff (FTP,
FILE and now SFTP) into a few simple utility functions to avoid this kind of
code duplications. But we can get your patch in first before we take on that
work.

> Comments welcome. I've tested using rexxcurl (as that's the way I want to
> use), and used various resumes for up & download for sftp only (verified
> with md5sum). I have used an error code CURLE_FTP_COULDNT_USE_REST where
> perhaps I should create an SFTP specific code. I can provide the original
> patch file, but when I posted with an attachment it didn't show up (I assume
> the list doesn't allow attachments).

It did show up (yesterday) and it does allow attachments.

I think you did the right thing to use the CURLE_FTP_COULDNT_USE_REST code,
but we should probably rename it to something more genericly to work in a
protocol agnostic way.

> If anyone spots errors or potential improvements then please let me know and
> I can quickly rework this and test.

It looked fine, although I would really like to ask you to follow the curl
style indent rules: 2 spaces for each level.

> I may look at making a similar change for scp, but this would not be
> typically used in the same way (and may not be simple), but if it's
> considered worthwhile I can have a go.

Is it even possible?

> I will look at enabling compression. This would probably require a new
> CURLOPT_SSH_COMPRESS option (unless it could be generic ftp & sftp).

These days we most often go with more generic names and support as many
protocols for them as we can, so although we don't have support for FTP at
this point it might be a good idea to just call it CURLOPT_COMPRESS.
Unfortunately I don't think we can use the same option we use for HTTP
compression as that's working in a somewhat different way.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html