davidC wrote:

When a transmission is interrupted, I think WinSCP reconnects automatically and downloads the remaining files, but the interrupted file remains complete on the server and incomplete locally, and is downloaded completely the next day.

What makes you think so? Do you have a log file showing that?

Our scheduled task daily creates a new local folder, connects (open ftps:...), and downloads XML files to that new folder, deleting those files from the server (get * -delete -preservetime -transfer=ascii -neweronly -filemask="|*/" -resumesupport=on). Sometimes the end of a file is missing locally, but file is complete in next day's local folder. (Each day's files are not named the same as files of any other day.) When a transmission is interrupted, I think WinSCP reconnects automatically and downloads the remaining files, but the interrupted file remains complete on the server and incomplete locally, and is downloaded completely the next day. When a file download is interrupted, I don't care whether only the remainder is downloaded, or the entire file is downloaded again, as long as it is downloaded completely. I assumed "resume" meant to resume the connection, and resume downloading the files, and resume trying to download the interrupted file, even if the entire file needs to be downloaded again, but maybe it means downloading only the remainder of a file. If WinSCP uses temporary file names, I could detect when a file is not complete, but that feature is not always available. Thank you for your help.

davidC wrote:

When a connection is lost, what happens after automatic reconnection, such as to a file that had downloaded partially?

Sorry, I do not understand what you mean by "such as to a file that had downloaded partially".

What if the file size is less than the transfer endurance threshold?

If you use the -resume switch, the transfer is resumed. But you should not use the switch in general, when doing mass upload. Because you may end up combining different versions of files.

What if the get command has -resume, -transfer=ascii, -resumesupport or -neweronly switches?

WinSCP never resumes files in ASCII/text mode.

Why is temporary file naming tied to whether the beginning of a file is re-downloaded?

Do not understand the question.

And why would you want temporary file naming only for binary files over a threshold size?

Binary files: It's not about binary files, but binary transfer mode. In text/ascii mode, particularly, when file conversion is done by the server, you cannot tell, what part of the file the server has. Because you only know a file size of a converted file, but that won't tell you, what was the size of an original file.
Threshold size: Because there's some overhead with checking existence of a partial file and renaming of the file. When transferring zillions of tiny files, you can tell the difference. It's configurable, so you can change it.

And why would you want temporary file naming only for binary files over a threshold size?

When a connection is lost, what happens after automatic reconnection, such as to a file that had downloaded partially?
What if the file size is less than the transfer endurance threshold?
What if the get command has -resume, -transfer=ascii, -resumesupport or -neweronly switches?
Why is temporary file naming tied to whether the beginning of a file is re-downloaded?
I reread the documentation, but I'm still confused.
I use ftps (FTP with implicit encryption) and SFTP protocols in WinSCP 5.7.7 (with all preferences at default) on Windows 2012R2sp1.
I run "winSCP.com /script=ftp.txt" via Windows Task Scheduler.
File ftp.txt has: get * -delete -preservetime -transfer=ascii -neweronly -filemask="|*/".
Thank you.