Lost connection; Timeout detected

I'm using WinSCP invoked from the command line to run a script. In the script there is a keepuptodate command. In the console window, I can see WinSCP sitting there happily for a while watching for changes.

But more often than not the watch ends prematurely with the following:

Lost connection.
Timeout detected.
Could not retrieve directory listing
Session 'xxx@yyy.com' closed.


How do I stop the watch being cut short by such dropped connections?

Thanks,

Mike

What version of WinSCP are you using? Since 4.1.2 WinSCP should keep the connection alive while watching for changes even in scripting.

I'll check on the version later, but it was downloaded from your site only yesterday -- so 4.1.5 I assume. Do I have to enable some option, or does it do keepalive by default?

Thanks,

Mike

P.S. Is there any difference between "synchronize remote" and "keepuptodate"?

Yes, it's 4.1.5 build 410.

Any idea how to stop these timeouts? If I could get this to work it would be perfect!

Thanks,

Mike

drmrbrewer wrote:

Any idea how to stop these timeouts? If I could get this to work it would be perfect!

Try to set keepalives interval to lower value

drmrbrewer wrote:

P.S. Is there any difference between "synchronize remote" and "keepuptodate"?

The "synchronize remote" is one-shot synchronization, while "keepuptodate" is continuous.

martin wrote:

Try to set keepalives interval to lower value

I think my problem will be that (even if this helps) you can't change the keepalives setting in a script? Or can you?

This keepuptodate function is only of value to me if it is started automatically on login and runs in the background, rather than having to start up WinSCP manually each time I log in to set up the keepuptodate. I ask WinSCP to keepuptodate via a script I invoke on login.

So, is it possible to change the keepalives setting in a script?

Mike

P.S. I shall certainly investigate changing keepalives in WinSCP to see if it helps at all.

Great. I think lowering the keepalives interval *does* work. I lowered it to 10 secs and it seems to be keeping the connection (I'm using FTP). I had tried switching to passive mode, and thought that was working, but in fact I still got a disconnection after a while. I'm testing this in WinSCP itself.

So, now how do I set keepalives from a script (which is the only place I would find it useful to use "keepuptodate")? I note that the open command has the following switches:

-privatekey=<key> Private key path
-timeout=<sec> Server response timeout
-hostkey=<fingerprint> Specifies fingerprint of expected host key.
-passive Passive mode (FTP protocol only)

Unfortunately, no keepalives switch. Any chance of this being added? From a site search, I note that there was a similar request about two weeks ago, but no resolution or answer.

Kind regards,

Mike

Edit: I just discovered https://winscp.net/eng/docs/commandline. Can I use the following to do what I want:

winscp.exe [session] /keepuptodate [local_directory] [remote_directory] [/defaults]

Do I understand correctly that the "keepalives" setting would come from the stored session, so I can set it to what I require to keep my connection alive when invoked as above? With this, would I be able to invoke it as a background task e.g. on login, as I would require?

drmrbrewer wrote:

Do I understand correctly that the "keepalives" setting would come from the stored session, so I can set it to what I require to keep my connection alive when invoked as above? With this, would I be able to invoke it as a background task e.g. on login, as I would require?

Correct. BTW, the same is true for scripting, if you use stored session name as parameter to "open"

martin wrote:

BTW, the same is true for scripting, if you use stored session name as parameter to "open"

This application of yours just becomes more and more useful as I learn more about it! I hadn't really noticed the "open <stored session>" method of opening a connection with a script command -- just what I want!

Thanks for your help, Martin, and for this very well thought-out application of yours!

Mike