Concurrent RealTimeSync requests

[banjo-p]

I have the following scenario:

S0. Windows 7 ultimate, FreeNAS connected via LAN
S1. I have set up two FreeFileSync batch jobs and verified that they work properly. Each is for a different source/target pair (ST1 and ST2, say), mirroring a directory on the C: drive with its equivalent on the NAS server
S2. Using Task Scheduler, I created two Windows Tasks (T1 and T2, say), each activated at log on, each runs RealTimeSync - one RealTimeSync request for each FreeFileSync batch job mentioned in #1 above


What I observe:

O1. The first task (T1) in S2 above, seems to work as intended. Any change made at any time to either the source directory or the target directory is mirrored
O2. The second task (T2) does not seem to mirror any changes
O3. I can see that T2 has run at log on because it has created a Log entry for the task (saying that there was nothing to synchronise - correct)
O4. If I manually run T2 from Task Scheduler, any existing changes are reflected properly. However if I make another change to the either ST2 directory, that new change is not reflected (it looks like the second RealTimeSync process is asleep).
O5. If I now make a manual change to ST1, that change is reflected properly

From a user's perspective, it appears that the second RealTimeSync request (and I would expect all subsequent requests) is/are dormant --or-- they are not chained, meaning that only the first request is being honoured

Hopefully the above description is accurate enough to be understood. Any help would be appreciated

regards, Steve

[Zenju]

From a technical perspective there are no dependencies between two RealtimeSync processes. I suggest simplifying the test case and see if the problem can be reproduced when starting the two RealtimeSync processes manually to make sure Windows Task Planner is not part of the problem.

[banjo-p]

From a technical perspective there are no dependencies between two RealtimeSync processes. I suggest simplifying the test case and see if the problem can be reproduced when starting the two RealtimeSync processes manually to make sure Windows Task Planner is not part of the problem.

Thanks for the quick response Zenju.

The short response to your suggestion is that it does not make any difference. However, in following your advice, I noticed I had omitted a technical point that appears to be relevant: the updates to ST2 are made via FTP (my scanner uses FTP to transfer a scanned document to a specified destination).

When I make changes to ST2 using Windows facilities (e.g. create new file, rename/delete existing file), BOTH methods work as expected. When the update is made using FTP, BOTH methods fail equally.

[Zenju]

The RealtimeSync application is quite simple, basically all it does is to register interest in changes to a particular directory. It's then responsibility of Windows to satisfy this request. Windows on the other hand delgates to the drivers of a particular drive to send notifications upon change. And here we're running third-party software with various quality of implementation problems, the most common being "silent failure".
So unfortunately there is nothing the RealtimeSync application could do about this (sad) state of affairs since responsibility for these bugs (or is it missing features?) is a few software layers deeper. If you're an idealist, you could try to find out who wrote the drivers for the device which does not properly send change notifications and file a bug report there... I wouldn't blame you if you're not.

[banjo-p]

Thanks Zenju for some really important information about what is happening under the covers. Seeing the one end of my folder pair (the one that is updated by the scanner) is on FREENAS and exposed to Windows via a CIFS share, I guess it would be unreasonable to expect FREENAS to publish the fact that it had updated something exposed via a Windows share.

So I created an IIS FTP site on my Windows 7 machine and got it to update the other side of the folder pair. Problem solved! The FTP process on Windows does sucessfully publish an update that RealTimeSync detects and which is then propagated to the NAS box.