I have 4 computers in 4 separate physical locations (miles apart). I have a
vpn set up so that each computer can "see" the other three and can establish
mapped network drives easily. I have one folder (with about 25000
subdirectories with a total of 50000 files) that I would like to see identical
on all machines. All four users can make modifications (including deleting and
creating new files). Can RealtimeSync work for me to keep all 4 computers in
sync? I can see setting up computer a with a source on computer a and a target
on computer b, a target on computer c and a target on computer d. Similarly,
computer b could be running with a source on computer b and a target on
computer a, a target on computer c and a target on computer d. Extend that to
computers c and d to complete the picture. Will RealtimeSync work or will it
find itself in some sort of infinite loop?
If the above won't work, is there a way to set it up so that it *will* work?
Thanks
Multiple computers possible?
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Hi Anon,
more important than using RealtimeSync, which is the second step, is
determining a useful sync-strategy. In your case I'd suggest a star-like
layout:
A
/\
|
\/
B <-> X <-> C
/\
|
\/
D
Let's assume there is an additional computer X, which is solely used for
synchronizing all other computers. Whenever you logon to one of the computers
A, B, C, or D, you first sync in automatic mode against X which always has the
relevant data. As soon as you are finished working, you sync again, to update
X.
In order to save this additonal computer, you can use any of the four
computers as X, the only important thing is that it should always be
accessible:
A <-> B <-> C
/\
|
\/
D
Now to RealtimeSync: It may be that syncing once before working on a computer
and once after work is not sufficient. In this case you can use RealtimeSync
to automatically start sync whenever data changes on your local or remote PC
X(or B in the second variant).
Just one note: Make sure that multiple syns from different computers against X
don't interfere! If you are the only user, this is no problem, but if there
are multiple users working at the same time, this may occur! In this case I'd
suggest a simple locking alogorithm, to ensure that only one sync is running
at a time against X.
For example use a locking file on X: Before starting sync create a dummy file
on X named "lock", after syncing, delete it again. Sync may only start, if
"lock" is not available on X or could wait until the file is not existing
anymore.
PS: When using automatic mode it may be that conflicts occur, if files have
been changed on both sides. You could get really fancy, by using a silent
batch job by default, but if any errors occured (returns with errorlevel < 0),
run an equivalent *.ffs_gui file to start the sync in gui mode, allowing you
to resolve conflicts. This is quite simple to setup. The new release v3.3 will
contain a description in the helpfile with a sample *.cmd file.
Regards, Zenju
more important than using RealtimeSync, which is the second step, is
determining a useful sync-strategy. In your case I'd suggest a star-like
layout:
A
/\
|
\/
B <-> X <-> C
/\
|
\/
D
Let's assume there is an additional computer X, which is solely used for
synchronizing all other computers. Whenever you logon to one of the computers
A, B, C, or D, you first sync in automatic mode against X which always has the
relevant data. As soon as you are finished working, you sync again, to update
X.
In order to save this additonal computer, you can use any of the four
computers as X, the only important thing is that it should always be
accessible:
A <-> B <-> C
/\
|
\/
D
Now to RealtimeSync: It may be that syncing once before working on a computer
and once after work is not sufficient. In this case you can use RealtimeSync
to automatically start sync whenever data changes on your local or remote PC
X(or B in the second variant).
Just one note: Make sure that multiple syns from different computers against X
don't interfere! If you are the only user, this is no problem, but if there
are multiple users working at the same time, this may occur! In this case I'd
suggest a simple locking alogorithm, to ensure that only one sync is running
at a time against X.
For example use a locking file on X: Before starting sync create a dummy file
on X named "lock", after syncing, delete it again. Sync may only start, if
"lock" is not available on X or could wait until the file is not existing
anymore.
PS: When using automatic mode it may be that conflicts occur, if files have
been changed on both sides. You could get really fancy, by using a silent
batch job by default, but if any errors occured (returns with errorlevel < 0),
run an equivalent *.ffs_gui file to start the sync in gui mode, allowing you
to resolve conflicts. This is quite simple to setup. The new release v3.3 will
contain a description in the helpfile with a sample *.cmd file.
Regards, Zenju
Hi, Zenju,
First, many thanks for the almost instantaneous and very thoughtful response!
Yes, one of the computers is "always available", so making that the "star" is
easy enough. So, for purposes of this discussion, I'll go with "B" being the
"hub" as you defined. In fact, "B" can be further restrained as belonging to
somebody who uses it 100% of the time in "read only" mode. Hence, no changes
ever initially take place on "B". That should make things a bit easier in the
long run.
I was hoping to use an automatic sync strategy, but it sounds like things
could get confused if RealtimeSync is used by A and C to sync with B at the
same time. I wasn't sure whether the locking strategy you described could be
used in conjunction with RealtimeSync or not. If it *can*, then I think we are
where I need to be.
I look forward to v3.3 with its helpfile description and sample *.cmd file.
Thanks again.
First, many thanks for the almost instantaneous and very thoughtful response!
Yes, one of the computers is "always available", so making that the "star" is
easy enough. So, for purposes of this discussion, I'll go with "B" being the
"hub" as you defined. In fact, "B" can be further restrained as belonging to
somebody who uses it 100% of the time in "read only" mode. Hence, no changes
ever initially take place on "B". That should make things a bit easier in the
long run.
I was hoping to use an automatic sync strategy, but it sounds like things
could get confused if RealtimeSync is used by A and C to sync with B at the
same time. I wasn't sure whether the locking strategy you described could be
used in conjunction with RealtimeSync or not. If it *can*, then I think we are
where I need to be.
I look forward to v3.3 with its helpfile description and sample *.cmd file.
Thanks again.
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> "B" can be further restrained as belonging to somebody who uses it 100% of
the time in "read only" mode.
That's nice but isn't even necessary. With the second layout having B as hub,
it even would be the only PC that could change all data without doing any
synchronization at all! Because whenever B changes data or any of the other
PCs it is their task to sync against B.
> but it sounds like things could get confused if RealtimeSync is used by A
and C
That doesn't have to do with RealtimeSync at all. RTS is just some means of
executing some arbitrary commandline whenever certain directories change data.
You could achieve the same effect by triggering the sync manually, but this is
kind of inconvenient.
But using a locking mechanism is needed anyway in order to avoid reading and
writing to a data-source at the same time. This is because sync performs in
two steps: 1. it reads data 2. it copies data. Between 1 and 2 it doesn't
expect changes. If there are changes anyway the tool is programmed to handle
all kinds of error situations gracefully. But anyway, we don't don't want to
challenge it if it ain't necessary, do we?
If the example with locking is not clear, here is a sample:
> :tryAgain
if not exist C:\lock (
::create the lock
echo This is datasource A creating a lock file > C:\lock
::execute the synchronization batch job silently
start /wait "C:\Program Files\FreeFileSync\FreeFileSync.exe"
"H:\Silent_Config.ffs_batch"
if not errorlevel 0 (
::if something went wrong, start FreeFileSync in GUI mode
start /wait "C:\Program Files\FreeFileSync\FreeFileSync.exe"
"H:\GUI_Config.ffs_gui"
)
del C:\lock
) else (
::wait 5 seconds then try starting sync again:
choice /C:AB /T:5 /D:A > NUL
goto tryAgain
)
the time in "read only" mode.
That's nice but isn't even necessary. With the second layout having B as hub,
it even would be the only PC that could change all data without doing any
synchronization at all! Because whenever B changes data or any of the other
PCs it is their task to sync against B.
> but it sounds like things could get confused if RealtimeSync is used by A
and C
That doesn't have to do with RealtimeSync at all. RTS is just some means of
executing some arbitrary commandline whenever certain directories change data.
You could achieve the same effect by triggering the sync manually, but this is
kind of inconvenient.
But using a locking mechanism is needed anyway in order to avoid reading and
writing to a data-source at the same time. This is because sync performs in
two steps: 1. it reads data 2. it copies data. Between 1 and 2 it doesn't
expect changes. If there are changes anyway the tool is programmed to handle
all kinds of error situations gracefully. But anyway, we don't don't want to
challenge it if it ain't necessary, do we?
If the example with locking is not clear, here is a sample:
> :tryAgain
if not exist C:\lock (
::create the lock
echo This is datasource A creating a lock file > C:\lock
::execute the synchronization batch job silently
start /wait "C:\Program Files\FreeFileSync\FreeFileSync.exe"
"H:\Silent_Config.ffs_batch"
if not errorlevel 0 (
::if something went wrong, start FreeFileSync in GUI mode
start /wait "C:\Program Files\FreeFileSync\FreeFileSync.exe"
"H:\GUI_Config.ffs_gui"
)
del C:\lock
) else (
::wait 5 seconds then try starting sync again:
choice /C:AB /T:5 /D:A > NUL
goto tryAgain
)