Apologies, I know this is a laundry list of questions re RealTimeSync...
Trying to get clarity about the triggers for RealTimeSync, so let me outline
how I think it works. Please correct as necessary and help me understand if we
have configured RealTimeSync for the best degree of success to ensure we
trigger as often or as soon as possible.
We have the following directories configured for monitoring:
<Directories>
<Item>%PCXPATH%</Item>
<Item>%csidl_MyDocuments%</Item>
<Item>%csidl_Desktop%</Item>
<Item>%csidl_Favorites%</Item>
<Item>%userprofile%\Application Data\Microsoft\Office\Recent</Item>
</Directories>
<snip>
<Delay>1200</Delay>
%PCXPATH% is just an environment var we set to point to the server and share
for the backup, so that RealTimeSync will only run if the client is on our
network and can see the backup target - great feature, and thank you for that!
My assumption is that RealTimeSync is monitoring only changes in the root of
the directories being monitored.
If a person changes %csidl_MyDocuments%\myWordFile.docx, RealTimeSync will
detect that, but if a person modifies
%csidl_MyDocuments%\MySubDirectory\myWordFile.docx, RealTimeSync will NOT
detect that change.
Is this assumption correct?
Because of this assumption (and the fact that a lot of people will be making
changes to files in sub-directories of the monitored directories), I have
added to the list the directory that keeps track of recent Office documents.
If clients open any Office document from the local drives or from a network
share, this directory will get updated, and RealTimeSync will trigger off that
change. This should help ensure that we are triggering backups frequently
enough to ensure we are getting all file changes in a timely manner.
Let's assume, though, that we find we are not triggering a backup frequently
enough, in which case I would need to add some additional directories to
monitor. How "expensive" is it to monitor directories? Is there a performance
or memory hit for monitoring directories?
I also tried to monitor the %TEMP% directory, but thought I received an error
about not being able to monitor the %TEMP% directory. Can we in fact monitor
%TEMP% for changes? If so, this seems like a good option, or we could monitor
"Temporary Internet Files" - any thoughts?
Finally, the documentation states that: "The name of the last changed file is
written to an environment variable named "changed_file". I do not see this
environment variable when I list them, so when does this environment variable
get set and populated? Is it created on the fly by RealTimeSync until the
command line it is running is completed and then %changed_file% gets dropped?
Thanks again, so far our pilot is going along quite well and no performance
problems to report from our users at all! Great stuff...
RealTimeSync questions
- Posts: 74
- Joined: 17 Mar 2008
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> <Delay>1200</Delay>
For such a long delay, you may consider to just run the sync job
unconditionally every 20 minutes via Windows Task Planner. This could be
simpler to setup than the RTS/FFS combo.
> only changes in the root of the directories being monitored
RTS monitors subdirectories as well!
> How "expensive" is it to monitor directories
It's basically free, since this feature is supported by the OS. RTS just
registers interest to the OS, then waits until it is notified of changes.
However there are a few special cases, e.g. removal of monitored top
directory, that cannot be notified by the OS. To solve this RTS has to check
base directory existence once per second. Due to the OS buffering file I/O the
performance of this operation is negliable.
> Can we in fact monitor %TEMP% for changes
This is just a folder like any other, so this should work.
> when does this environment variable get set and populated
This environment variable can only be seen in the context of RTS or other
programs that RTS calls directly. RTS does not set this as a global
environment variable (this isn't an easy thing to do anyway and would require
admin privileges).
For such a long delay, you may consider to just run the sync job
unconditionally every 20 minutes via Windows Task Planner. This could be
simpler to setup than the RTS/FFS combo.
> only changes in the root of the directories being monitored
RTS monitors subdirectories as well!
> How "expensive" is it to monitor directories
It's basically free, since this feature is supported by the OS. RTS just
registers interest to the OS, then waits until it is notified of changes.
However there are a few special cases, e.g. removal of monitored top
directory, that cannot be notified by the OS. To solve this RTS has to check
base directory existence once per second. Due to the OS buffering file I/O the
performance of this operation is negliable.
> Can we in fact monitor %TEMP% for changes
This is just a folder like any other, so this should work.
> when does this environment variable get set and populated
This environment variable can only be seen in the context of RTS or other
programs that RTS calls directly. RTS does not set this as a global
environment variable (this isn't an easy thing to do anyway and would require
admin privileges).
- Posts: 74
- Joined: 17 Mar 2008
Thanks for the reply, I did some testing to see this all in action.
I used Process Explorer to look at the environment var you set in RealTimeSync
and yes, it's there.
I made a single change to a file 10 levels deep in "My Documents", and when
RealTimeSync triggered, I could see in %changed_file% that it was in fact that
file 10 levels deep - so that is great! Monitoring "My Documents" will trigger
for any file change from that folder down - excellent.
I then checked back later to see what if any changes might have triggered, and
it was a file from a separate user directory on our backup share, and then I
realized that we are asking RealTimeSync to subscribe to changes to the entire
share, and that is clearly not right, so I have updated our config to monitor
%pcxpath%\%username%\config, so that any given user is only checking for and
monitoring a personal folder to be available on the network rather than the
root of the share. See, piloting does work (grin)!
As for the delay and the scheduled task, we are shying away from the 20 min
task for two reasons:
1. We would need to create the task with credentials for that user and that does require input from the client or we have to write a script to do that for the person with no credentials prompt or UAC.
2. It would fire off every twenty mins regardless of any local changes or if the person can see the backup server and I really want to preserve that efficiency: only run IF you can see the backup server AND there has been a change to monitored directories.
I appreciate the guidance on the "expense" of monitoring directories, I will
add some minor ones and remove %TEMP%, that's not really a useful change to
see.
I used Process Explorer to look at the environment var you set in RealTimeSync
and yes, it's there.
I made a single change to a file 10 levels deep in "My Documents", and when
RealTimeSync triggered, I could see in %changed_file% that it was in fact that
file 10 levels deep - so that is great! Monitoring "My Documents" will trigger
for any file change from that folder down - excellent.
I then checked back later to see what if any changes might have triggered, and
it was a file from a separate user directory on our backup share, and then I
realized that we are asking RealTimeSync to subscribe to changes to the entire
share, and that is clearly not right, so I have updated our config to monitor
%pcxpath%\%username%\config, so that any given user is only checking for and
monitoring a personal folder to be available on the network rather than the
root of the share. See, piloting does work (grin)!
As for the delay and the scheduled task, we are shying away from the 20 min
task for two reasons:
1. We would need to create the task with credentials for that user and that does require input from the client or we have to write a script to do that for the person with no credentials prompt or UAC.
2. It would fire off every twenty mins regardless of any local changes or if the person can see the backup server and I really want to preserve that efficiency: only run IF you can see the backup server AND there has been a change to monitored directories.
I appreciate the guidance on the "expense" of monitoring directories, I will
add some minor ones and remove %TEMP%, that's not really a useful change to
see.
