Disabling resume support with INI file for .NET 5.1.4

Hi, I'm using the .NET interface with WinSCP 5.1.4 and I am intermittently running into the resume / rename file error.

https://winscp.net/tracker/834

WinSCP.SessionRemoteException: Transfer was successfully finished, but temporary transfer file 'BottomlineDocument_S_00004425.pdf.filepart' could not be renamed to target file name 'BottomlineDocument_S_00004425.pdf'. If the problem persists, you may try to turn off transfer resume support.

I am aware that support has been added for disabling the resume feature using the .NET interface in 5.2 but this is only in beta and is not a stable release yet.

I'd like to disable the resume feature using an INI file, but as I haven't used an INI before and I can't find much in the way of documentation for these files I'd like to check here that I'm using it correctly.

The session log appears to state that no configuration is being used, the session log file starts:

. 2013-11-02 12:12:50.979 --------------------------------------------------------------------------
. 2013-11-02 12:12:50.979 WinSCP Version 5.1.4 (Build 3020) (OS 5.2.3790 Service Pack 2)
. 2013-11-02 12:12:50.979 Configuration: nul

If I create a file named WinSCP.ini and place it next to the WinSCP.exe file with the following content will that disable the resume feature?

[Configuration\Interface\CopyParam]
ResumeSupport=2

Taken from https://winscp.net/forum/viewtopic.php?t=11460

Is "2" the correct value to disable the resume feature?

Is this the only content required in the INI file?

Thanks in advance for any assistance.

WinSCP .NET assembly is deliberately isolated from any external configuration by default.
You can override that with Session.DefaultConfiguration = false:
https://winscp.net/eng/docs/library_session#properties

Though note that this use is not supported.
I believe that using 5.2.5 beta is safer.

Anyway, your INI file looks good.

Thanks for the information. Since I had to make a code change either way I tried the 5.2.5 beta release. Looks good so far.

I can see in the session log so I don't think my original problem will reoccur (though, of course, I haven't been able to reproduce it since the last post anyway...).