Disable transfer to temporary file name/transfer resume support, as the error message suggests.
In .NET assemby, you can do that using TransferOptions.ResumeSupport.
https://winscp.net/eng/docs/library_transferresumesupport
https://winscp.net/eng/docs/resume#automatic

The SFTP account doesn't have delete permission, and the server could have failed the removal instead of replying with Status code :0 and keep the file silently (I can check).
With no delete permission, how to make sure the files are not synced multiple times. Client and server are in different timezone, is it good enough to use Size as criteria Vs either. Thanks.

Then the second session started, only ME40040-2003294-20171204_115802-Sensor000-Patient002.txt has existed in the remote folder.

There's only single SSH_FXP_OPEN in the second log. So only one file was created (the ME40040-2003294-20171204_115802-Sensor000-Patient002.txt.filepart)

When the upload finished, WinSCP sended SSH_FXP_REMOVE to remove ME40040-2003294-20171204_115802-Sensor000-Patient002.txt. And the server confirmed the removal ("Status code: 0")

So if the server consequently failed the rename and if you can see both ME40040-2003294-20171204_115802-Sensor000-Patient002.txt.filepart and ME40040-2003294-20171204_115802-Sensor000-Patient002.txt after the upload, I do not think it's a fault of WinSCP. Check server log file.

martin wrote:

Please attach a full session log file showing the problem (using the latest version of WinSCP).

Please see the attached log which shows the behaviour, in the first run it synchronized 7 files (which are new) and in the next run it again selected the same 7 files and started to sync and failed subsequently. While doing the sync for the second time, it again created the ME40040-......-Patient002.txt.filepart and throws exception that the file cannot be renamed as there is a file with the same name exists.

What could be the reason? The client and server are running in different timezone and i used -criteria="either" and -preservetime flags.

Mohan Anandan wrote:

Other thing about using $synchronizationResult.Check(), it doesn't proceed to sync other new files if there are any (above said)conflicts exists? Just exits with exception unless some one cleans the files at sftp server.

Given that script is going to run on a un-monitored system, how to get all the new files into SFTP server even though there are some conflicts / exception with previous session exists?

It's not possible currently with Session.SynchronizeDirectories. It always stops on the first error.

Unfortunately, I didn't enable the session logs during the activity. Like I said, its not happening all the times and hard to reproduce.

Other thing about using $synchronizationResult.Check(), it doesn't proceed to sync other new files if there are any (above said)conflicts exists? Just exits with exception unless some one cleans the files at sftp server.

Given that script is going to run on a un-monitored system, how to get all the new files into SFTP server even though there are some conflicts / exception with previous session exists?

Thanks.

Mohan Anandan wrote:

Any idea, why it is creating the filename and .filepart together?

I do not think that WinSCP ever does that.

Please attach a full session log file showing the problem (using the latest version of WinSCP).

While doing the $session.SynchronizeDirectories operation, it seems at times the target directory consists of the file name as well as filename.filepart files.
And WinSCP is trying to rename the .filepart to original file and complains that the file already exists, Error code:4.

Any idea, why it is creating the filename and .filepart together? ideally .filepart would be the first. It does every time though but at times i see this case.

Because of this error, it doesn't synchronize any new files present in the source directory. I used $synchronizationResult.Check()

PS: The user does not have overwrite permission on the target directory and therefore the Error Code:4 has been thrown.

Any advice on this? Thanks.