RealTimeSync delay options / changedfile logs

[mfreedberg]

Hello again!
We are getting close on our sync solution, which includes a piece of wrapper
code before we run RealTimeSync, which when it triggers, runs another piece of
VBscript which then runs FreeFileSync. While all this is really working quite
well, we have two issues I could use some help or advice on.

The first issue has to do with RealTimeSync actually triggering. We have our
delay set quite high, because we will have a lot of people running this, and
we need to load balance, so our RealTiimeSync is set for 20 mins. This should
help ensure that we do not run too often, causing frequent network hits, but
rather only run a few times an hour at best and bundle the backup event. What
we are seeing, however, is that RealTimeSync is not firing every twenty mins
even though there are changes to the directories it is monitoring (a network
directory so that we know we are online, "My Documents", Desktop, Favorites,
and %temp%). I can see from Process Explorer that the internal environment var
changedfile is set to something,but RealTimeSync is not triggering. Is that
delay simply too long for RealTimeSync or is something else possiby going on?

The second item is related...is there a debug option we can enable, or a more
verbose logging option, to track *all the file changes* that RealTimeSync has
been notified of during the delay period? We would love to confirm that it is
in fact seeing our changes before the delay is up and the tool kicks off its
command line.

Thanks again!

[Zenju]

> RealTiimeSync is set for 20 mins


With such a long delay, there's the question whether it would be a simpler
setup to not use RTS, but schedule your script in Windows Task Planner to fire
every 20 minutes unconditionally.


> What we are seeing, however, is that RealTimeSync is not firing every twenty
mins


The "delay" used to be called "minimum idle time" since this what it really
is: the command will not be executed until there has been a "cool-down" time
with *no* disk activity of the specified amount of seconds. This helps to
avoid starting FFS in the middle of another I/O-heavy operation. With 20min
however this is likely to never happen, except when nobody is using the
network share anymore.


> more verbose logging option


You might try using "cmd /c echo "%changed_file%" >> c:\log.txt" as command
line (as described in the help file), maybe as a second RTS instance. It's
clunky but works.

[mfreedberg]

The reason we do not use the scheduled task has to do with the automation of
the task creation as well as the fact that we are using the RealTimeSync
feature that it will only run if all monitored directories are available, so
we monitor a single, otherwise unused, directory on the network share so that
we know we are online.

Minimum Idle Time is quite different than cool down time - so we should really
set this for something like 60 seconds or perhaps 5 minutes? We are trying to
avoid running it too often, but this might mean we take a different approach
to our backup process.

[Zenju]

> 60 seconds or perhaps 5 minutes?


This totally depends on your disk usage patterns. The window should be large
enough to very likely be available after someone has used the share.

[mfreedberg]

One thing to clarify: the directory we monitor on the share is one that nobody
uses, it's basically a flag directory (%synctarget%\online), so that
RealTimeSync will only become active if the client is on the network - because
they can see this flag directory. The only changes they should be getting
notified of by the OS are the ones for the local directories we monitor.

We are experimenting now with two values (2 minutes vs 5 minutes) - and we
will compare the "fire rates" of those two based on the sync log and determine
which one is a better fit.

Thanks again for the answers!