>>> 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.
>
> Ah, I didn't realize you meant that you'd pass in the size libcurl should
> expect the remote file to have. I find that a very weird option and I
> wouldn't like it. If it would be an option, it should rather disable the
> SIZE command and just completely live without it (it already can do it
> since SIZE is not an RFC959 command). It will then try to fetch the size
> from the RETR response and as a last resort simply don't bother with
> size-related checks.
in fact, disabling the check itself would maybe not be that bad... because
of the SIZE dependence on TYPE :(
as I do a LIST command I presumed that I could give the size, but in fact it
is not sure at all that at would be OK (however I expect to make only binary
transfers, so there should not be problems)

>>> 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.
>
> Yes, the condition is simply: if the path is the exact same as in the
> previous transfer.
>
>> 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.
>
> And it does in fact store the state in the 'SessionHandle' struct which is
> wrong (but doesn't really matter as it is now since it gets stored every
> time as you noted), the state MUST be moved to the connectdata struct if
> it is to be set once.
ok i'll study that.

>> I use the 7.15.4 zip, should I update something to have the patches more
>> easily applicable?
>
> Well, at least 7.15.5 as of today, but I really recommend using CVS
> directly when working on patches since at times we do biggish changes.
so i'll try to do that.

Armel
Received on 2006-08-08