Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Username

Subject

Message body

Font colour:

Font size:

[quote="nbutkowski"]@martin: Thank you for your response. My comment was probably a poor choice of words. If a client doesn't wait for a response to [m]SSH_FXP_CLOSE[/m] (and handle that appropriately), then it's setting up [m]SSH_FXP_REMOVE[/m] to fail. Instead, it's safer for WinSCP to wait. But I don't know what the program is doing under the hood, so I could be entirely mistaken.

Particularly I think the client is exposed here because the server may not have yet released the resources but the client will assume it has.
[quote]
   The response to this request will be a SSH_FXP_STATUS message.  Note
   that on some server platforms even a close can fail.  For example, if
   the server operating system caches writes, and an error occurs while
   flushing cached writes, the close operation may fail.

Note that the handle is invalid regardless of the SSH_FXP_STATUS
   result.  There is no way for the client to recover a handle that
   fails to close.  The client MUST release all resources associated
   with the handle regardless of the status.  The server SHOULD take
   whatever steps it can to recover from a close failure and to ensure
   that all resources associated with the handle on the server are
   correctly released.[/quote][/quote]

Options

Disable BBCode in this post

Notify me when a reply is posted (registered users only)

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

Filename

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

File Comment

Options

Private file (available to author and site moderators only)

Topic review

nbutkowski

2020-05-05 15:29

@martin: Thank you for clarifying. It looks like the order of processing commands is correct serverside, but maybe the servers internal queueing can be improved. I still feel it would be safer to document any behavioral differences between get -delete and get + rm.

martin

2020-05-05

nbutkowski wrote:

If a client doesn't wait for a response to SSH_FXP_CLOSE (and handle that appropriately), then it's setting up SSH_FXP_REMOVE to fail. Instead, it's safer for WinSCP to wait.

Please read again the quote in my previous post. The server must process the requests in the correct order.

And btw, the way most SFTP servers are implemented (particularly OpenSSH), they won't even know/care that the other requests were sent before the client got a responses. They read a request from the connection, process it, send a response, and only then they read another request, etc.

And during the 17 years that WinSCP supports SFTP, I've never seen an SFTP server that has any problem with this.

nbutkowski

2020-05-01 20:01

@martin: Thank you for your response. My comment was probably a poor choice of words. If a client doesn't wait for a response to SSH_FXP_CLOSE (and handle that appropriately), then it's setting up SSH_FXP_REMOVE to fail. Instead, it's safer for WinSCP to wait. But I don't know what the program is doing under the hood, so I could be entirely mistaken.

Particularly I think the client is exposed here because the server may not have yet released the resources but the client will assume it has.

The response to this request will be a SSH_FXP_STATUS message. Note
that on some server platforms even a close can fail. For example, if
the server operating system caches writes, and an error occurs while
flushing cached writes, the close operation may fail.

Note that the handle is invalid regardless of the SSH_FXP_STATUS
result. There is no way for the client to recover a handle that
fails to close. The client MUST release all resources associated
with the handle regardless of the status. The server SHOULD take
whatever steps it can to recover from a close failure and to ensure
that all resources associated with the handle on the server are
correctly released.

martin

2020-05-01

nbutkowski wrote:

The behavior with the -delete flag appears to conflict with the SFTP specification.

How does it conflict?
I believe it perfectly conforms to the specification:
https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-4.1:

In other
words, if an application submits multiple requests to the server, the
results in the responses will be the same as if it had sent the
requests one at a time and waited for the response in each case.

nbutkowski

2020-04-30 20:47

The behavior with the -delete flag appears to conflict with the SFTP specification. Specifically, the client should wait for an SSH_FXP_STATUS message from SSH_FXP_CLOSE before SSH_FXP_REMOVE is sent to the server. Can anyone with access to the source for WinSCP confirm the expected behavior? I will try to recreate it, but without access to see what's happening or to contribute a fix, I don't know how to handle this.

Guest

Question about winscp GET -delete and SSH_FXP_STATUS with SFTP

2020-04-29 14:35

I've noticed with one of our users is having issues deleting files from our server. We tracked things down to their winscp batch script not waiting for SSH_FXP_STATUS after sending SSH_FXP_CLOSE. The script quickly moves onto SSH_FXP_REMOVE. Is this a known issue with the get command with the -delete flag in WinSCP? Sorry if there's a better source for this information, I was unable to find it. I don't have the client's exact software information, but I can get it.

Here's an example log from our server which demonstrates WinSCP's behavior:

2020-04-27 11:55:32,027 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] Received message (SSH_FXP_CLOSE) 

2020-04-27 11:55:32,027 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] OnClose() 

2020-04-27 11:55:32,027 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] Queued FXP_CLOSE for file handle 939632750 

2020-04-27 11:55:32,027 DEBUG SFTPConnection [Session.2188476:Default Site:testuser:123.456.789.10] PreProcessPacket pt=SSH_MSG_CHANNEL_DATA,len=76 

2020-04-27 11:55:32,027 DEBUG SFTPConnection [Session.2188476:Default Site:testuser:123.456.789.10] SSH_MSG_CHANNEL_DATA for channel 0 

2020-04-27 11:55:32,027 DEBUG SSHServerChannel [Session.2188476:Default Site:testuser:123.456.789.10] Channel 0: ProcessPacket pt=SSH_MSG_CHANNEL_DATA 

2020-04-27 11:55:32,027 DEBUG SFTPServerMessageFactory [Session.2188476:Default Site:testuser:123.456.789.10] Received message (type=13,len=76) 

2020-04-27 11:55:32,027 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] Received message (SSH_FXP_REMOVE) 

2020-04-27 11:55:32,027 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] OnFileRemove(/outgoing/test.txt) 

2020-04-27 11:55:32,027 DEBUG WindowsAdapter [Session.2188476:Default Site:testuser:123.456.789.10] Exception thrown while service_account was accessing test.txt - System.IO.IOException:The process cannot access the file 'test.txt' because it is being used by another process. 

2020-04-27 11:55:32,027 DEBUG FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] Closing file handle 939632750 

2020-04-27 11:55:32,042 INFO FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] Closed file /Root/partner/outgoing/test.txt after reading 4 bytes 

2020-04-27 11:55:32,042 DEBUG FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] Notifying stream closed 939632750 

2020-04-27 11:55:32,042 DEBUG FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] Notified stream closed 939632750 

2020-04-27 11:55:32,042 DEBUG FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] File /Root/partner/outgoing/test.txt: 0 messages to process 

2020-04-27 11:55:32,042 DEBUG FileDetails [Session.2188476:Default Site:testuser:123.456.789.10] Removed file handle 939632750 

2020-04-27 11:55:32,042 DEBUG SFTPSubsystemServer [Session.2188476:Default Site:testuser:123.456.789.10] Sending SSH_FXP_STATUS [requestid=47108,code=0]

Post a reply

Topic review

Question about winscp GET -delete and SSH_FXP_STATUS with SFTP

Documentation

Support

Associations

Follow Us