Bug 1558

Summary: Sftp client does not correctly process server response messages after write error
Product: Portable OpenSSH Reporter: Simon <simm42>
Component: sftpAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED WORKSFORME    
Severity: normal CC: djm, MrUmunhum
Priority: P2    
Version: 4.3p2   
Hardware: amd64   
OS: Linux   

Description Simon 2009-02-20 02:05:54 AEDT
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.
Comment 1 Damien Miller 2009-02-20 20:35:03 AEDT
openssh-4.3p2 is very old and I think this bug has been fixed since then. Can you reproduce it with a recent version?

Note that the recent version has implemented a few extensions already and documents them in the PROTOCOL file shipped in the source distribution. More extensions are planned too (see bug #1555).
Comment 2 Damien Miller 2010-06-18 13:11:24 AEST
Six months with no response == no bug.
Comment 3 Damien Miller 2011-01-24 12:34:07 AEDT
Move resolved bugs to CLOSED after 5.7 release