$session.SynchronizeDirectories left file.filepart and file and throws the error

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.

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).

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:

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.

martin wrote:

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).

martin wrote:

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

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.

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:

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.

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.

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.

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