On Wed, 21 Jan 2004, Joe Halpin wrote:

> Sounds like a "bad situation" would be for any previous I/O operation to
> have encountered an error. In that case, it seems like the previous
> operation should have the side effect of recording the failure somehow.

Yes, and in general all functions return an error code if they failed in any
way.

> If we want to consider that any failure is a show-stopper, one possibility
> is that we could add a flag to the FTP struct that says whether or not the
> connection is still valid. Anything that does I/O would need to check this
> flag.

Yes. I don't think this is a general problem now, as I believe an error is
propagated back all the way and if that is the case nothing else is attempted
on that connection.

> That sounds like too much work and too much of a maintenance problem to me.

I think you exaggerate this problem. Just take precations so that your
additional code does the right thing.

> I'm not sure I understood what you meant by "changing the function pointer
> prototype" though. If you're talking about changing the pointers so they
> invoke error handling routines rather than doing I/O, that sounds good to me
> as well.

I meant that perhaps we should make the Curl_ftp_disconnect() function accept
a function argument for 'error code from the transfer'. Then you could for
example skip the QUIT-sending if it isn't CURLE_OK... and if you change that
prototype, you will need to change the function pointer that calls it, which
then would require a few other functions to be changed as well...

Either that, or you store the error code in the ftp struct and check that
before you send quit.

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.

> We might have to call exit() in there someplace though.

No. libcurl is a library, it never exits. It simply bails out and return error
if things don't work.

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