We may be using an account with an upload file size limit. Will let you know if we run into any issues when using an account with unlimited upload size. That might be what was breaking our connections and causing auto-resume to fail and/or removing the partially-uploaded file; in that case, it's server-side anyway. Sorry about that :D

PrimeHydra wrote:

It would be easier if we could configure it so that put doesn't delete the partially-uploaded file when connection breaks. Is this possible?

I do not think it does (without reason).
Can you attach (or email me) a complete session log file showing that?

martin wrote:

Please provide me a complete log. That snippet does not help at all.

The documentation says that auto-resume on synchronize works only with SFTP protocol; we use regular FTP.

Please provide link to the documentation. It's not true or it's misunderstanding.

It would be easier if we could configure it so that put doesn't delete the partially-uploaded file when connection breaks. Is this possible?

If not, I'll pursue the automatic-resume-with-synchronize, but I've tried just about everything on that front. Docs here say that Auto-reconnect and resume is supported only in SFTP (I have resume enabled in options): https://winscp.net/eng/docs/resume#broken_connection

Thanks.

Please provide me a complete log. That snippet does not help at all.

The documentation says that auto-resume on synchronize works only with SFTP protocol; we use regular FTP.

Please provide link to the documentation. It's not true or it's misunderstanding.

martin wrote:

Auto-resume for FTP should work too. Please attach a full log file showing the problem (using the latest version of WinSCP).

Hi Martin,

Thanks for your response.

Here's a sample of the part of the log where it's restarting the synchronize upload rather than resuming it:

< 2013-04-15 12:45:26.483 Script: Lost connection.
< 2013-04-15 12:45:26.499 Script: <Empty directory listing>
< 2013-04-15 12:45:26.499 Disconnected from server
< 2013-04-15 12:45:26.499 Copying files to remote side failed.
< 2013-04-15 12:45:26.499 Timeout detected.
< 2013-04-15 12:45:26.499 Opening BINARY mode data connection.
< 2013-04-15 12:45:26.686 Script: Lost connection.
< 2013-04-15 12:45:26.686 Script: <Empty directory listing>
< 2013-04-15 12:45:26.686 Disconnected from server
< 2013-04-15 12:45:26.686 Copying files to remote side failed.
< 2013-04-15 12:45:26.686 Timeout detected.
< 2013-04-15 12:45:26.686 Opening BINARY mode data connection.
< 2013-04-15 12:45:26.686 Copying files to remote side failed.

... and so on.

This is using the synchronize command with WinSCP.com. Have also tried it with WinSCP.exe.

The documentation says that auto-resume on synchronize works only with SFTP protocol; we use regular FTP.

Is there a way to get synchronize to auto-resume broken uploads, or will I need to write some sort of script that runs put commands with -resume until no error is returned?

Update: Since there doesn't seem to be auto-resume for broken synchronize to normal FTP, I'm trying a batch file that issues winscp.com with a put command until the errorlevel is 0 (no error returned from the put). I'm using option batch abort. Here's the problem: If my connection breaks, the partially-uploaded file gets deleted. Is there a way to prevent this? This approach will work if it could just preserve the partially-uploaded file so I can resume it on the next "put" attempt.

Thanks!

Auto-resume for FTP should work too. Please attach a full log file showing the problem (using the latest version of WinSCP).

We use WinSCP to automatically upload our software builds. The files we upload can be rather large, so auto-resume of broken connections is important. While WinSCP supports auto-reconnect, it doesn't seem to auto-resume FTP transfers. Since manual FTP resumes are supported, why not automated using synchronize? This feature would be a huge benefit. If this is already possible, please let me know how I need to configure my settings. Thanks!