Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Session log file, please, not XML log.

Attached log supplied by client showing five separate connections to pull files. As you can see in the second and third connections, the same file is available to collect. The 'server closed connection' was generated at our end when the client first collected the file successfully, therefore leaving the file in the mailbox which the client then collected a second time.

Re: Server shutdown before transfer could complete!

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

To generate log file, use /log=path_to_log_file command-line argument. 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.

Server shutdown before transfer could complete!

I'm guessing this is a fairly regular issue, but I haven't been able to find it while searching so starting a new thread. Apologies in advance if traipsing over old ground...

I have a client connects in using winscp to pull files from a mailbox on our server. For some reason, they connect in, disconnect, then re-connect in to pull files. Occassionally, when they have transferred the last file, we get "Server shutdown before transfer could complete!" for the comms session and the last file they collected is left in the mailbox as the host server does not get notification of it having been picked up successfully. Then when the client connects in again, the file is still present in the mailbox so is transferred again. We advised the client to put an ls -lrt prior to issuing the quit; but this has had no effect.

This is the script the client is using in batch mode:

"option batch abort\n" +
"option confirm off\n" +
"option transfer binary\n" +
"open " + SESSION + "\n" +
"get -speed=512 " + REMOTEPATH + "*" + " \"" + LOCALPATH + "\n" +
"ls -lrt\n" +
"close\n" +

Any thoughts would be gratefully received.