Multiple Jobs in seqential manner

[jaizck]

I have created a batch job with two folder pairs as below
1.(A folder in USB) & A local folder in D Drive
2. A local folder in E drive and A local folder in F Drive.

This job was given to RealTimeSync and everything is fine until I unmount the USB stick. When I unmount the USB, RealTimeSync pauses waiting for the USB location to be available, But the 2nd job is also paused. Is it like that the jobs are done in sequential manner and proceed to next only if previous one is successful?

[Plerry]

RealTimeSync should have no problem, but obviously FreeFileSync (FFS) can not execute its defined sync as one of its specified resources is not available. And therefore FFS does not execute its sync (at all).

The two pairs of your sync are fully unrelated.
It is then better to simply create two separate batch sync configurations for pair 1 and for pair 2, and create individual RealTimeSync jobs for these two batch configurations. This is faster, as both syncs have a more limited, relevant scope and are invoked less frequently. It is also more robust against "odd" conditions, as there are no interdependencies between both syncs.

[xCSxXenon]

RTS will stop monitoring if one of the locations it is monitoring is not available. Other than that clarification, Plerry is right, you have to split those into two RTS and FFS jobs

[jaizck]

RealTimeSync should have no problem, but obviously FreeFileSync (FFS) can not execute its defined sync as one of its specified resources is not available. And therefore FFS does not execute its sync (at all).

The two pairs of your sync are fully unrelated.
It is then better to simply create two separate batch sync configurations for pair 1 and for pair 2, and create individual RealTimeSync jobs for these two batch configurations. This is faster, as both syncs have a more limited, relevant scope and are invoked less frequently. It is also more robust against "odd" conditions, as there are no interdependencies between both syncs.

Thanks for the reply. You mean to say that if there are no interdependent batch jobs, it is better to have two separate instance of RealTimeSync. ie two RTS will be running with separate jobs. I expected a single instance of RTS with two threads

[Plerry]

Particularly when combining FFS with RTS, it is best to limit the scope of monitored folders per RTS instance and associated FFS syncs as much as possible.
Assuming a simple A(<)=>B and C(<)=>D sync case, there is no need for a change (detected by RTS) in A or B, to trigger a sync that also includes C and D. And obviously vice versa.

By splitting into two FFS syncs and two corresponding RTS instances, the A(<)=>B sync will only be run upon detecting changes in A or B and will run faster than a combined sync, because it does not unnecessarily need to compare C vs. D. Similarly, the C(<)=>D sync will only be run upon detecting changes in C or D and will run faster than a combined sync, because it does not unnecessarily need to compare A vs. B.

Additionally, by splitting, any unavailability of A and/or B will not block changes in C or D to trigger and run the C(<)=>D sync. And vice-versa.

[jaizck]

Particularly when combining FFS with RTS, it is best to limit the scope of monitored folders per RTS instance and associated FFS syncs as much as possible.
Assuming a simple A(<)=>B and C(<)=>D sync case, there is no need for a change (detected by RTS) in A or B, to trigger a sync that also includes C and D. And obviously vice versa.

By splitting into two FFS syncs and two corresponding RTS instances, the A(<)=>B sync will only be run upon detecting changes in A or B and will run faster than a combined sync, because it does not unnecessarily need to compare C vs. D. Similarly, the C(<)=>D sync will only be run upon detecting changes in C or D and will run faster than a combined sync, because it does not unnecessarily need to compare A vs. B.

Additionally, by splitting, any unavailability of A and/or B will not block changes in C or D to trigger and run the C(<)=>D sync. And vice-versa.

Thank you very much. Only thing that was bothering me was, If I have n folder pairs, there will be n RTS process running in my PC.

[xCSxXenon]

That is correct, but on my systems I am only seeing a 7MB memory usage for each instance, and CPU is essentially non-existent