>> No, it doesn't. I was wrong. We need to decide that another way.
>
> I've thought about this issue some more.
>
> The only reason we want/need this "cancel" info, is to know whether or not
> to read/wait for the server response in Curl_ftp_done(), right?
>
> But what if you remove a handle very early in the progress when libcurl
> issues a long series of PWD commands? You could still manage to do that
> exactly when a command has been sent and before a response has been
> (completely) received...
>
> I guess what I'm trying to say is: this problem is somewhat more
> complicated than at least I previously were thinking.
I'm trying to find a definitive solution to that. In fact there two cases at
hand, either the buffer was sent totally, or it was not.

If it was sent totally, we can definitely go on with a ABOR command [only
necessary if a data connection was there or to be opened]
If it was sent partially, we have no other choice than finishing current
buffer, else the server may get a truncated command which actually means
something else. then we can proceed with the above case.

This kind of 'flush' before cancel must be done synchronously with respect
to user expectations (because the free of the easy will come probably some
lines further), but it should not be a problem because FTP commands are
usually extremely short with respect to the size of the usual TCP buffers.

Armel
Received on 2006-12-14