PuTTY bug sftp-close-status

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Psftp doesn't check return value for SSH2_FXP_CLOSE request
class: bug: This is clearly an actual problem we want fixed.
difficulty: fun: Just needs tuits, and not many of them.
priority: medium: This should be fixed one day.
present-in: 0.60
fixed-in: 6f871e3d226bc837e98b59649d323c6df5fc7f8a (0.68)

From a user:

Psftp doesn't check return value for SSH2_FXP_CLOSE
request. The specifictaions of sftp protocol state:
"The response to this request will be a SSH_FXP_STATUS
message.  One should note that on some server
platforms even a close can fail. This can happen e.g. 
if the server operating system caches writes, and an
error occurs while flushing cached writes during the
close."
http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt

The server we use will identify failure when closing
the file. Currently psftp doesn't give any indication
of the failure. 

Psftp should check the return value and if close is
not succesfull after writing to a file, 
user should be informed about failed file transfer
operation.

psftp -h
PuTTY Secure File Transfer (SFTP) client
Release 0.60

The problem happens at least on Windows, but I would
assume that it affects all platforms. 

Unfortunately the only server I know that has this
problem is not shared in public (only sold to certain
group of organizations), so mentioning it wouldn't
help as you wouldn't be able to test it anyway. But
the problem should be quite trivial to fix without
testing. 

The server in question doesn't overwrite old file if
such exists with the same name, if closing fails. So
please don't try to use stat() or similar to find out
if the transfer was successful, even if close fails.
If close fails, file is not transfered. 
Audit trail for this bug.


If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2017-02-18 23:12:41 +0000)