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
> works
> fine even without SIZE support.
>
> Which is why I ask you for the details of your error case.

okay.

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://user:passwd@server.domain//file

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 ?

Immanuel