Hi. We have initiated multiple RTS. and we noticed that it only has a time when it will initiate the command to be set. When does it exactly check the path in the watch folders for any changes? Does it monitor all the time?
Current Scenario is I have RTS on a Mirror Job. And its not always running even when changes are done on watchfolder.
Is it better to do it as Update instead? Though update is not really good because if something is deleted from the source, its not deleted on the destination.
How frequent does the checking on the watch folder run? Any way we can see it? From the manual it doesn't show.
Realtime Sync WatchFolder
- Posts: 3
- Joined: 19 Sep 2024
-
- Posts: 2946
- Joined: 22 Aug 2012
From the RealTimeSync Manual page:
1)
"RealTimeSync receives change notifications directly from the operating system in order to avoid the overhead of repeatedly polling for changes."
This is essentially instantaneous and continuous.
2)
"Each time a file or folder is created/updated/deleted in the monitored directories or their sub directories, RealTimeSync waits until a user-configurable idle time has passed in which no further changes were detected, and then runs the command line. This makes sure the monitored folders are not in heavy use when starting a synchronization."
A first change will start the Idle Time timer. If new changes occur during Idle Time timing, the timer starts timing from 0 again. Only when the timer reaches the full Idle Time, the command line is executed.
3)
"The command line usually starts a synchronization task using FreeFileSync which naturally leads to additional file change notifications. Therefore, the RealTimeSync change detection has to be deactivated to not go into an endless loop. On the other hand, it is not likely that changes (other than those from FreeFileSync) happen in first place since RealTimeSync runs the command line only after the user-specified idle time has passed. In any case, files changed during the execution of FreeFileSync will be synchronized the next time FreeFileSync runs."
You wrote:
> And its not always running, even when changes are done on watchfolder.
This should only be the case if:
A) those changes occur during idle timing (Situation 2 above).
As soon as no further changes occurred in the RTS monitored folder(s) within idle timing, RTS will launch the sync. And thus sync all relevant changes.
B) (Further) changes occur during the execution of the sync launched by the RTS command line.
This is the above situation 3. Any such changes will not trigger a renewed sync, but will normally be synced during the next sync, as triggered by any changes that occurred after your sync has ended.
1)
"RealTimeSync receives change notifications directly from the operating system in order to avoid the overhead of repeatedly polling for changes."
This is essentially instantaneous and continuous.
2)
"Each time a file or folder is created/updated/deleted in the monitored directories or their sub directories, RealTimeSync waits until a user-configurable idle time has passed in which no further changes were detected, and then runs the command line. This makes sure the monitored folders are not in heavy use when starting a synchronization."
A first change will start the Idle Time timer. If new changes occur during Idle Time timing, the timer starts timing from 0 again. Only when the timer reaches the full Idle Time, the command line is executed.
3)
"The command line usually starts a synchronization task using FreeFileSync which naturally leads to additional file change notifications. Therefore, the RealTimeSync change detection has to be deactivated to not go into an endless loop. On the other hand, it is not likely that changes (other than those from FreeFileSync) happen in first place since RealTimeSync runs the command line only after the user-specified idle time has passed. In any case, files changed during the execution of FreeFileSync will be synchronized the next time FreeFileSync runs."
You wrote:
> And its not always running, even when changes are done on watchfolder.
This should only be the case if:
A) those changes occur during idle timing (Situation 2 above).
As soon as no further changes occurred in the RTS monitored folder(s) within idle timing, RTS will launch the sync. And thus sync all relevant changes.
B) (Further) changes occur during the execution of the sync launched by the RTS command line.
This is the above situation 3. Any such changes will not trigger a renewed sync, but will normally be synced during the next sync, as triggered by any changes that occurred after your sync has ended.
- Posts: 3
- Joined: 19 Sep 2024
Hi Plerry. Thanks for the highlights. This is what confuses us.
We tried to make same everything but instead of mirror, we used Update, now every time there is changes on the watch folder, the batch run. When it was on Mirror, its running very rare. Does mirror behave differently on RTS? And mirror doesn't create DB file because we didn't enable it from the setting,
When it was on Mirror, it doesn't run until we trigger it again to mirror. so RTS on Mirror felt like it was useless. If we enable the db, will it check the folder and sync accordingly?
We tried to make same everything but instead of mirror, we used Update, now every time there is changes on the watch folder, the batch run. When it was on Mirror, its running very rare. Does mirror behave differently on RTS? And mirror doesn't create DB file because we didn't enable it from the setting,
When it was on Mirror, it doesn't run until we trigger it again to mirror. so RTS on Mirror felt like it was useless. If we enable the db, will it check the folder and sync accordingly?
-
- Posts: 4866
- Joined: 11 Jun 2019
The db file shouldn't have any effect on RTS functionality. Mirror should also work perfectly fine with RTS, I am using it without issue. You said you have multiple RTS sessions running, does anything change if you enable them one at a time and verify functionality before starting the next one?
-
- Posts: 2946
- Joined: 22 Aug 2012
In line with xCSxXenon's reply:
RTS will simply launch its command line, and is fully unaware if that launches an FFS Mirror sync, an FFS Update sync (or any other application for that matter). RTS is therefore also fully unaware of the fact that a sync it may launch uses a database or not.
If your observation of the difference between your Mirror and Update sync are correct, it sounds like a mistake in the Mirror sync job or the RTS task you use to launch the Mirror sync.
If your Update sync runs as expected, I would suggest to open the saved Update *.ffs_batch configuration in the FFS GUI (after backing up the original), only modify the variant from Update into Mirror and disable the database, and save it under the same name, and use your RTS configuration previously used to launch your Update, not Mirror sync.
RTS will simply launch its command line, and is fully unaware if that launches an FFS Mirror sync, an FFS Update sync (or any other application for that matter). RTS is therefore also fully unaware of the fact that a sync it may launch uses a database or not.
If your observation of the difference between your Mirror and Update sync are correct, it sounds like a mistake in the Mirror sync job or the RTS task you use to launch the Mirror sync.
If your Update sync runs as expected, I would suggest to open the saved Update *.ffs_batch configuration in the FFS GUI (after backing up the original), only modify the variant from Update into Mirror and disable the database, and save it under the same name, and use your RTS configuration previously used to launch your Update, not Mirror sync.
