>>> No, there's no such way. You may know the size already but libcurl
>>> doesn't and it needs to know the size to properly detect transfers that
>>> are cut off prematurely.
>
>> is it imagineable to add an option such as "CUROPT_EXPECT_SIZE_LARGE"?
>> which would prevent this request?
>
> It would be imagineable to have a way to disable certain parts of the FTP
> command/response, yes. But I don't see why it would be called
> CUROPT_EXPECT_SIZE_LARGE. What does a large size have to do with this?
uh, maybe CURLOPT_EXPECTEDSIZE_LARGE (LARGE because it would be
curl_offset_t, which is the name for big sizes if I remember well). It would
be the expected size for the download, we could put it in data->downloadsize
instead of -1 near the start of a download and we would jump the SIZE
command.

>> I noted as well that curl redo all the CWD stuff for each file even if
>> the previously downloaded file was in the same directory (idem for TYPE
>> A/I),
>
> No it doesn't. At least not recent versions if the connection was kept
> alive.
it seems to actually keep the path in certain conditions.

> The type it will resend, yes.
>
>> could it be possible/wishable to memorize in the curl FTP context that
>> the last download was in same path and/or same type? and redo the minimal
>> stuff?
>
> Yes it would.
it seems that the transfer type is set at several places, by code very
similar to ftp_transfertype (but non-blocking variant)
there are already several places were "data->ftp_in_ascii_mode" is set
(every time), so testing it could do the trick. RFC959 states that "TYPE A"
is the _default_ so we could put his value at initialization time.

>> I want to make large number of small files downloads, these additional
>> roundtrips (wrt to a pure FTP lib) may degrade dramatically the
>> performances.
>
> Yeps, they might. I would gladly accept patches that avoid the extra TYPE.
I use the 7.15.4 zip, should I update something to have the patches more
easily applicable?

Armel
Received on 2006-08-07