On Fri, 14 Nov 2008, Andreas Wurf wrote:

>> Within the ftp_done() function there's a call to Curl_GetFTPResponse().
>> That is supposed to wait for the response from the server. It would be
>> interesting to learn if that call somehow isn't called or if it returns
>> with some kind of "wrong" info or similar when this bug occurs.
>
> It's hard to find something if you don't know what to look for ;-) So far, I
> could not observe anything special.

Yes I understand that, but I have the reversed situation that I can't repeat
the problem so I have a hard time to do imaginary steps to track this down.

Anyway: when the bug occurs it seems Curl_GetFTPResponse() returns CURLE_OK
even though no response have in fact been read. This is what the analysis
points to.

Curl_GetFTPResponse() has basically a single loop within it that loops around
a call to ftp_readresp() that reads bits of the response. I can't see how the
function can avoid entering the loop and I can't see any flow of the code that
can make Curl_GetFTPResponse() return CURLE_OK for any other reason than that
ftp_readresp() fills in a non-zero value in the 'ftpcode' variable.

But I fail to see how ftp_readresp() can end up doing this.

Perhaps a start would be to add a check somewhere in Curl_GetFTPResponse()
that checks the size of the response line if everything is fine, as it should
be at least 4 bytes and in the buggy cases it has been zero (as no response
has been sent from the server yet).

> But: Why does libcurl send the "CWD /" at all?

It should only do that between transfers if it doesn't remember where it was
previously or if it needs to actually change dir. If you enable
CURLOPT_VERBOSE you should get some hints on the lib's reasoning around that.

-- 
  / daniel.haxx.se