Library: globus_ftp_control
file: globus_ftp_control_client.c
In the 4.1.0 release: line 876

There's a problem with the arithmetic used when coping the next message to the
front of the response buffer after receiving a non-perliminary GSS-encoded
response. Just after the user callback completes:

        memcpy(cc_handle->response.response_buffer,
           &cc_handle->read_buffer[end_of_reply],
           response_length-end_of_reply);

end_of_reply is an index into the transformed (first message decoded)
response_buffer (transformed courtesy of globus_l_ftp_control_end_of_reply). So
what you get is a short index into read_buffer that returns the latter half of
the first encoded message. My fix was to keep things simple since the
transforming function is kind enough to place the second encoded message after
the decoded message in the response_buffer.

memcpy(cc_handle->response.response_buffer,
      &cc_handle->response.response_buffer[end_of_reply],
       response_length-end_of_reply);

Or you could use the memcpy code in the former part of that conditional which I
assume works:

        memcpy(cc_handle->response.response_buffer,
           &cc_handle->read_buffer[
               nbytes-(response_length-end_of_reply)],
           response_length-end_of_reply);

That would probably be cleaner and allow more independence between this
function and the transforming function (IE this won't break when
globus_l_ftp_control_end_of_reply is changed to not pull up the second encoded
message).

This is a minor bug, I have never seen it occur outside of dealing with some
obscure firewalling issues which were causing XIO reads to return 2 server
completion responses as:

first read: first encoded message + first half of second encoded message
second read: second half of second encoded message