I'm in the process of implementing extensions to sftp-server. One of these is a maximum file size - if a write attempts to write past the maximum file size SSH2_FX_PERMISSION_DENIED is returned.

When the client receives this it displays permission denied on screen and stops the upload.

It then reports ID mismatch and exits.

sftp> put bigfile
Uploading bigfile to /bigfile
bigfile                                                                                                                                                      99%  199MB   6.7MB/s   00:00 ETACouldn't write to remote file "/bigfile": Permission denied
ID mismatch (6404 != 3)


As can be seen from my server log the permission denied error is returned to message id 6403 

Got message_type SSH2_FXP_WRITE 
write id 6403 handle 1 off 209715200 len 32768 
ERROR: Attempt to write greater than Max file size, offset: 209715200, data length:32809 



Message id 3 is a close request 



Got message_type SSH2_FXP_CLOSE 
close id 3 handle 1 


However there are several write requests (id 6404 to 6419) that the client has already sent to the servers input queue - I am assuming before it has received the error from the server. According to the sftp spec the server must respond to these packets, however the client appears to forget about the outstanding messages, performs the file close and expects the next response message it reads to be a response to the close, when in fact that message is 16 messages further down the queue.

The client should correctly handle all status messages for commands it has issued to the server, even where there has been an error.