[Bug 1558] New: Sftp client does not correctly process server response messages after write error

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1558

           Summary: Sftp client does not correctly process server response
                    messages after write error
           Product: Portable OpenSSH
           Version: 4.3p2
          Platform: amd64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sftp
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: simm42 at gmail.com


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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.