Martin, thank you for your reply. I did not know about this requirement, I will fix this within my server.

btimby wrote:

My theory is that WinSCP sends the rename operation after sending the file data, without waiting for the close operation to succeed.

Yes it does. And it's perfectly valid according to the SFTP specification.
See https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-4.1

Hello, I am the developer of an SFTP server. There is an apparent incompatibility between my server and WinSCP. The problem arises when using the file resume feature (upload to *.filepart, then rename to *). The rename is being performed early, before the uploaded file is actually closed. The nature of my server is that the file is not actually present until it is fully closed. Thus the rename operation fails.

My theory is that WinSCP sends the rename operation after sending the file data, without waiting for the close operation to succeed. I implemented a workaround in the server, which delays rename operations when the file name ends with ".filepart". This does fix many cases, but since this is a timing issue, it does not work in 100% of cases. In my testing, if I wait for completion of the close operation, the rename always succeeds.

I feel that this is a bug in WinSCP. The fact that my server receives a rename operation before replying to the close operation indicates this is the case. I am happy to provide more information if necessary.