Yep. Thanks for your help Martin.

OK, I was probably looking to the other log file (TEMP2_FTP.log), when I was checking the timestamps.

The issue appears to be the MoveIT SFTP server. I have outlined the issue on their support forum.

https://community.progress.com/s/question/0D54Q00007uR3uASAS/ls-and-stat-commands-return-different-timestamps

Essentially, the ls command does not provide the timestamp to the second. But the stat command does. BizTalk issues the ls command, downloads any files, then issues the stat command before it deletes the file. However, the stat command to MoveIT does report the seconds. So, to BizTalk it looks as if the file has changed, and as such does not issue a rm command.

I cannot say if it is relevant, as I do not know how BizTalk works. I'm not sure where/how the timestamps are evaluated in respect to:

Later when BizTalk tries to delete the file it tries to delete (rm) the file based on the initial ls(dir) time stamp which does not match.

But I can see a full timestamp in the ls log and it matches the stat timestamp later, so it's possibly not relevant.

I found this thread later that seems to indicate the BizTalk SFTP adapter may have issues with the MoveIT SFTP server. That is the server in this case.

https://web.archive.org/web/20230604221144/https://social.microsoft.com/Forums/mvpforum/en-SG/968d6724-55dd-40d0-935e-9e90359d814d/biztalk-2016-sftp-adapter-not-deleting-files?forum=biztalkgeneral

The WinSCP log files won't help here. The remove request does not make it to WinSCP. So what do you do in BizTalk to trigger the remove?

To add a little more color, we also attempted the same tests with redirection to versions 5.15.9 and 5.17.6 with the same result.

We have an issue where BizTalk 2020, using WinSCP 5.15,4, will not delete files from a particular server.

For one server, the SFTP adapter downloads a file, issues the rm script command, which deletes the file. (See attached TEMP2_FTP.log)

For another server (the one we're troubleshooting), the SFTP adapter downloads a file, but never issues the rm script command, so the file is never deleted. (See attached TEMP_FTP.log)

I am not terribly proficient with the logs to see if something might signal the SFTP adapter that it cannot delete the file, and as such it does not issue the rm command.