On Sat, 24 Jan 2004, Joe Halpin wrote:

> > In fact, I think I prefer getting the status stored in the struct, as then
> > we can probably also skip waiting for the 226/250 response in
> > Curl_ftp_done() using the same premises.
>
> I'm working on this approach, but I wanted to point out that a "valid"
> flag in the struct can't be absolutely counted on after calling
> Curl_ftpsendf(). That function may or may not detect a broken connection.
> Since the first send will probably always succeed (the return only indicates
> that the data was copied to the kernel's output buffer), we won't know until
> the second or possibly third send that the other side closed the connection,
> after we get an RST back.

Don't bother about that, as if that happens we'll either fail when sending the
QUIT or fail on waiting for the response from it.

> I guess I'll concentrate on Curl_ftpsendf() and Curl_GetFTPResponse(), and
> make sure the flag gets updated when it needs to. Are there any other I/O
> functions I'd need to look at?

I would probably suggest doing it at a somewhat higher level:

If Curl_ftp() executes all the way to the bottom the function, it ran fine. If
Curl_ftp_nextconnect() did the same, then libcurl has done everything up to
the transfer just fine without problems. No need to do anything about these
functions, they all abort and bail out nicely if they detect errors.

Then the transfer is made, and Tranfer() returns an error code for it. If that
is CURLE_OK, everything is still fine.

Then Curl_done() is called uncondtionally, which means it might be called even
if Tranfer() failed. Here's where this starts to get interesting. It isn't
called at all if one of the earlier functions failed. If you simply pass in
the 'res' variable to Curl_done() (when called from Curl_perform:transfer.c)
and from there to ->curl_done() you can use that variable as a hint on what to
do (or rather, what not to do if it already has failed).

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn