keepuptodate robust?

Advertisement

drmrbrewer
Joined:
Posts:
23
Location:
UK

keepuptodate robust?

How robust is keepuptodate? I'm finding that many files are being missed that are only picked up with a full synchronize after all the local changes are done. Is it possible that so many local changes are happening that winscp can't keep up? If this is a problem, would it help to have a "delay" option so that winscp would keep track of what changes have been made, but only start transferring after a specified delay, to allow local changes to have settled down?

I'm using this over FTP.

Mike

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
41,468
Location:
Prague, Czechia

Re: keepuptodate robust?

drmrbrewer wrote:

I'm finding that many files are being missed that are only picked up with a full synchronize after all the local changes are done.
Please try to describe in more details what do you mean by "all the local changes are done".

Is it possible that so many local changes are happening that winscp can't keep up?
It should not be problem generally. May depends on your answer above.

If this is a problem, would it help to have a "delay" option so that winscp would keep track of what changes have been made, but only start transferring after a specified delay, to allow local changes to have settled down?
There's a delay of 500ms currently. It can be changed in registry (or INI file) only.

Reply with quote

drmrbrewer
Joined:
Posts:
23
Location:
UK

I start a winscp keepuptodate on a folder (with subfolders), then set off a local website update that changes lots of files in the local monitored folders. I can see winscp kick into life and start sending stuff to the remote server, but when all has settled down and stopped, there have been several occasions when I can see that at least one of the local changed files has not been transferred. If I then run a synchronise job on the same folder to the same remote location, the missing files ARE transferred. I just wondered whether it was maybe that winscp couldn't deal with so many change notifications all at once, e.g. several files per folder, and several folders, all changing nearly at once.

How does the keepuptodate function work? Does it notice a change in a folder, and synchronise ALL files in that folder (transferring only changed files of course, after comparing local with remote), or does it know exactly which files have changed, and synchronise only those? If it is the former, say a big file C changes, and this starts winscp off transferring C, then WHILE C is tranferring, files A and B in the SAME folder change, is there a danger that A or B is overlooked because they are before C in some order within the folder (alphabetical and/or time)?

Mike

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
41,468
Location:
Prague, Czechia

drmrbrewer wrote:

How does the keepuptodate function work? Does it notice a change in a folder, and synchronise ALL files in that folder (transferring only changed files of course, after comparing local with remote), or does it know exactly which files have changed, and synchronise only those? If it is the former, say a big file C changes, and this starts winscp off transferring C, then WHILE C is tranferring, files A and B in the SAME folder change, is there a danger that A or B is overlooked because they are before C in some order within the folder (alphabetical and/or time)?
Yes the former is true. However I believe that Windows should trigger another change notification if A/B changes after C. So WinSCP should perform two synchronizations in row.

Reply with quote

drmrbrewer
Joined:
Posts:
23
Location:
UK

OK I just did some local changes within a folder that was being monitored by keepuptodate, and I *know* that an entire new folder -- created a few levels down within the monitored folder tree -- was missed.

I am monitoring the folder:

C:\Users\Mike\Documents\AAA\BBB\CCC\

And the following new folder XXX was created, with stuff inside it:

C:\Users\Mike\Documents\AAA\BBB\CCC\DDD\EEE\FFF\XXX\

The folder XXX and its contents were *not* transferred.

Other changes to files were made within the monitored folder tree, which *were* picked up.

FTP protocol.

Thanks,

Mike

Reply with quote

Advertisement

martin
Site Admin
martin avatar

Can you reproduce that? I'm not.
Was folder C:\Users\Mike\Documents\AAA\BBB\CCC\DDD\EEE\FFF\ existing before?
If it was, was there other change in the same folder apart of creating XXX subfolder?

Reply with quote

drmrbrewer
Joined:
Posts:
23
Location:
UK

Yes, C:\Users\Mike\Documents\AAA\BBB\CCC\DDD\EEE\FFF\ did exist before. So the XXX folder was created, and within XXX a single xml file, plus two further folders YYY and ZZZ, both YYY and ZZZ with files in them.

It was only when I ran a synchronise on the same folder (C:\Users\Mike\Documents\AAA\BBB\CCC\) to the same remote destination that folder XXX and its contents were transferred.

Mike

Reply with quote

martin
Site Admin
martin avatar

Thanks. Would be able to find the simplest possible case where the problem occurs? Like trying to set synchronization root to C:\Users\Mike\Documents\AAA\BBB\CCC\DDD\EEE\FFF\. Making only two folders (XXX and YYY). Creating no files in them, etc... thanks in advance.

Reply with quote

Advertisement

You can post new topics in this forum