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.

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

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?

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

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.

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

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.

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