cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: FTP SIZE command?

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Tue, 8 Aug 2006 00:02:52 +0200 (CEST)

On Mon, 7 Aug 2006, Armel Asselin wrote:

>> 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.

>> 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.

> 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.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-08-08