martin wrote:

SanskritFritz wrote:

I wish WinSCP would try to reconnect to the server when a watched dir is changed.

This issue is being tracked already.

I've added more feasible solution to the tracker.

CD wrote:

anyone have any ideas what the problem might be? i have tried playing around with scripting options, and have found the "batch continue" option to work better than the "batch on", and thought I had the problem licked, but apparently not.

In the first log the connection was automatically reestablished. WinSCP supports that only while transferring a file. In other cases it is not able to reconnect automatically. So in the first case it is possible that transfer was ongoing, while in the other case it were not.

Yes this is exactly the problem I had. So far the only solution was for me to start WinSCP from the Task Scheduler every 5 minutes and do a full synch like in your script. It is basically the same script without the keepupdate command.

I'm having this same issue. My script is "sometimes" terminated when network connection is temporarily lost.
Here's my script file:

option batch continue
option confirm off
option synchdelete off
option transfer binary
open ShellFBO
synchronize remote E:\dir1 /dir1
keepuptodate E:\dir1 /dir1

I say "sometimes" above because I have watched the script work through network connection problems in the past. Here's a couple excerpts from my log:

When the script worked through a network connection problem:
. 2008-04-15 02:58:57.564 Waiting for data timed out, asking user what to do.
. 2008-04-15 02:58:57.564 Asking user:
. 2008-04-15 02:58:57.564 Host has not answered for 15 seconds.
. 2008-04-15 02:58:57.564
. 2008-04-15 02:58:57.564 Wait for another 15 seconds? ()
. 2008-04-15 02:58:57.564 Attempt to close connection due to fatal exception:
* 2008-04-15 02:58:57.564 Terminated by user.
. 2008-04-15 02:58:57.564 Closing connection.
. 2008-04-15 02:58:57.564 Connection was lost, asking what to do.
. 2008-04-15 02:58:57.564 Asking user:
. 2008-04-15 02:58:57.564 Terminated by user. ()
. 2008-04-15 02:59:03.813 Looking up host "xfer1.shell.com"
. 2008-04-15 02:59:03.813 Connecting to 134.146.81.66 port 22
. 2008-04-15 02:59:04.079 Network error: Software caused connection abort
. 2008-04-15 02:59:04.079 Connection was lost, asking what to do.
. 2008-04-15 02:59:04.079 Asking user:
. 2008-04-15 02:59:04.079 Network error: Software caused connection abort ()
. 2008-04-15 02:59:10.329 Looking up host "xfer1.shell.com"
. 2008-04-15 02:59:10.329 Connecting to 134.146.81.66 port 22
. 2008-04-15 02:59:10.595 Network error: Software caused connection abort
. 2008-04-15 02:59:10.595 Connection was lost, asking what to do.
. 2008-04-15 02:59:10.595 Asking user:
. 2008-04-15 02:59:10.595 Network error: Software caused connection abort ()
. 2008-04-15 02:59:16.845 Looking up host "xfer1.shell.com"
. 2008-04-15 02:59:16.845 Connecting to 134.146.81.66 port 22
. 2008-04-15 02:59:17.110 Network error: Software caused connection abort
. 2008-04-15 02:59:17.110 Connection was lost, asking what to do.
. 2008-04-15 02:59:17.110 Asking user:
. 2008-04-15 02:59:17.110 Network error: Software caused connection abort ()
. 2008-04-15 02:59:23.360 Looking up host "xfer1.shell.com"
. 2008-04-15 02:59:23.360 Connecting to 134.146.81.66 port 22
. 2008-04-15 02:59:23.641 Network error: Software caused connection abort
. 2008-04-15 02:59:23.641 Connection was lost, asking what to do.
. 2008-04-15 02:59:23.641 Asking user:
. 2008-04-15 02:59:23.641 Network error: Software caused connection abort ()
. 2008-04-15 02:59:29.891 Looking up host "xfer1.shell.com"
. 2008-04-15 02:59:29.891 Connecting to 134.146.81.66 port 22
. 2008-04-15 02:59:32.422 Server version: SSH-2.0-VShell_3_0_1_478 VShell
. 2008-04-15 02:59:32.422 We claim version: SSH-2.0-WinSCP_release_4.0.6
. 2008-04-15 02:59:32.422 Using SSH protocol version 2

Here's an excerpt when the script terminated:
. 2008-04-15 09:10:11.013 Waiting for data timed out, asking user what to do.
. 2008-04-15 09:10:11.013 Asking user:
. 2008-04-15 09:10:11.013 Host has not answered for 15 seconds.
. 2008-04-15 09:10:11.013
. 2008-04-15 09:10:11.013 Wait for another 15 seconds? ()
. 2008-04-15 09:10:11.013 Attempt to close connection due to fatal exception:
* 2008-04-15 09:10:11.013 Terminated by user.
. 2008-04-15 09:10:11.013 Closing connection.

after the above error, the script was terminated, and the computer was sitting at the winscp> prompt.

anyone have any ideas what the problem might be? i have tried playing around with scripting options, and have found the "batch continue" option to work better than the "batch on", and thought I had the problem licked, but apparently not.

any advice is appreciated.

Thanks!

-Casey

martin wrote:

This issue is being tracked already.

Thank you, before posting I searched only the forum, not the tracker. My fault, sorry. Thanks for adding this thread as comment.

SanskritFritz wrote:

I wish WinSCP would try to reconnect to the server when a watched dir is changed.

This issue is being tracked already.

Oops, that is what I did just after your post. It wasnt obvious, sorry. But, the log i posted was with the continue option:

Can you please answer this:

martin wrote:

What does it do with "option batch continue"?

Is there a way to perform a "Synchronize on start" when starting Keepuptodate in script mode? The problem is this:
WinSCP detects a change in a local subdirectory and attempts to upload the files. But the server is not responding at the moment, so WinSCP aborts. After a while someone notices, that there are files missing on the server, so I restart WinSCP in script mode, so it starts to listen again. But those files not uploaded will not be updated on the server even if another directory is changed. If I am lucky, the same directory will be changed after a while, and then the older files are uploaded as well. So now I cannot initiate an automatic restart of WinSCP, I have to synchronise manually first before the restart.

PS: sorry, just found out that simply issuing a 'synchronize remote' command before the keepuptodate command will just do the trick...
So, I'm planning now to start WinSCP from the scheduler every 5 minutes and do a full synch. Not as elegant as the keepuptodate method, but hey, at least it works!

All I get is this in the log:I wish WinSCP would try to reconnect to the server when a watched dir is changed.
I tested with a local server (freeSSHd) by simply quitting the server, deleting a file in the watched directory, starting the server again, and deleting another file.

What does it do with "option batch continue"?

Hi, first thank you for this wonderful product!
Now to my problem:
I run Winscp as service on my windows server to keep the big unix server updated with incoming files (the files are created on the windows box). This is the command used:
This the PDFUpload.scp file:
Now, this should run all the time, however if a short network problem prevents connection to the server, the synchronisation halts with the following message in the logfile:.I know, the 'option batch on' means that "all prompts are automatically replied negatively". Is there a way to force positive answers to these kind of questions? I tried the options continue as well, but no success. Please help me! So far the only solution is to restart WinSCP.