WinSCP FTPS and Interrupted Transfer in Synchrony Gateway

Hi Martin,
I've just had an issue with Axway Synchrony Gateway and latest WinSCP 5.5.4. When we upload a file (FTPS) using winscp.com with a batch script, the file is received in the state "Interrupted" on Axway Synchrony Gateway.

To workaround this problem, we have to use an "ls" right after the "put" command. To me it seems, that the connection is closed "too early", causing the transfer to fail in Axway Synchrony Gateway. So the issue is still existing, maybe there was no relation to https://winscp.net/tracker/489 ?

Regards,
Tilo

The server acknowledged that a file transfer is complete:

< 2014-07-10 14:22:32.557 226 Closing data connection (network bytes 5530/file bytes 5530)

So I do not see what can be wrong. I can only imagine that although the server acknowledged the transfer, it's actually finishing writing asynchronously. And when control channel is closed before the asynchronous writing finishes, it's interrupted. But that would clearly be a server-side bug.

Anyway, can you tests this by delaying close in a way that does not involve communication with the server?
- If you are able to reproduce the problem in an interactive mode, just wait a sec after put finishes before typing close.
- If you are able to reproduce this from a script only, you can for example delay close by opening second session to a different server after put.

Can you also attach an example of log with ls workaround?

I've also had seen the 226 message. It only happens in batch mode. It really looks like an timing issue. See attachment for two logs, one with a closing ls (it works) and one without it (does not work).

In the log of the transfer which is working, you can't see the uploaded file in the first ls, this is due to an internal Synchrony Gateway routing capability. And WinSCP seems to automatically do another ls. But to me, this doesn't seem the problem, as this is the try where the transfer ends normally.

Thanks for the logs. I do not see anything suspicious in the logs.
Can you try my suggestion to delay close by opening second session to a different server after put? (or even attempt to connect to an invalid address or invalid port on the same server)