Re: SCP/SFTP and persistency, bug #1823487
Date: Thu, 22 Nov 2007 23:22:25 -0800 (PST)
On Thu, 22 Nov 2007, Daniel Stenberg wrote:
> I did a case just like that and it worked perfectly for me. As I explained
> before, the size is still stored with that function call. In my case it
> fine even without SIZE support.
> Which is why I ask you for the details of your error case.
I'm on Windows 2000, libcurl and curl are compiled with MS Visual Studio.
The command i used is:
curl -v -P "-" -o todelete.tmp --stderr curl-7.17.2-20071116_ftp.log
ftp.log shows the output of the curl command tool
curl-7.17.2-20071116_ftp.log shows the progress of
the curl command tool
Using the snapshot of November 15th, the filesize is
set by a call to Curl_pgrsSetDownloadSize(). This function
is called 3 times. See call_stack_071115.log. The actual
filesize is set when the transfer is actually starting.
Using the snapshot of November 16th, Curl_pgrsSetDownloadSize()
is called 2 times (call_stack_071116.log)
In my error case, curl does the parsing of the "opening data
connection for ..." string. It successfully obtains the filesize
and passes it to Curl_setup_transfer(). The latter assigns it to
data->reqdata.size, but doesn't do anything with it, it just
plays around with data->reqdata.keep.size.
Not really sure what else i can tell you.
Which of the calls to Curl_pgrsSetDownloadSize() in your case
sets the real filesize ? (not 0 or -1)
Does curl do the parsing of the string in your case ?
- application/octet-stream attachment: ftp.log
- application/octet-stream attachment: curl-7.17.2-20071116_ftp.log
- application/octet-stream attachment: call_stack_071116.log
- application/octet-stream attachment: call_stack_071115.log