I'm using Lubuntu and FreeFileSync to mirror two external NTFS USB drives with the master shared via Samba to other networked Windows machines (strange kind of software RAID, I won't go into reasoning for this approach but it does make some sense, honest).
Anyway, with RealtimeSync monitoring changes, if a new text file is created using a Windows machine and then the name is changed, the sync errors (i.e. the new text file doesn't exist any more).
If errors are reported, clicking retry after this error seems to work. If errors are ignored then the new file also gets ignored.
The mirror needs to be fully automatic so the work around that seems to work most of the time is using the retry option in FreeFileSync (10 times, delay 1 second). And running everything else fully 'silent' i.e. close popup afterwards, run minimised & ignore errors.
But in testing a file still slipped through (was ignored). Is there another setting somewhere that might help?
RealtimeSync Mirror File Update Issue
- Posts: 11
- Joined: 13 Oct 2014
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
In RealtimeSync you can set a *minimum idle time*, default is 10 seconds. If you leave it at default it should delay synchronization while users are still working on a particular file.
- Posts: 11
- Joined: 13 Oct 2014
I've tried 10 seconds and 60 seconds. Both minimum idle times exhibit the problem.
(the 1 second delay I mentioned is for retrying after an error)
(the 1 second delay I mentioned is for retrying after an error)
- Posts: 11
- Joined: 13 Oct 2014
What it 'looks' like is happening is; when a file system change occurs the file name is recorded, after the minimum time elapses, info for this now missing file is requested, this causes an error, but if retry is pressed the new file name is used?
I know this is probably not what actually happens, but hopefully this sheds some light on what 'could' be happening?
I know this is probably not what actually happens, but hopefully this sheds some light on what 'could' be happening?
- Posts: 11
- Joined: 13 Oct 2014
Also, when copying 876 files in 11 folders with a total size of 14.4 GB from a Windows machine to the Master disk on Lubuntu what I've found is that the mirror doesn't appear to work.
RealtimeSync minimum idle time is 60 seconds, FreeFileSync error retry is 5 times with a delay of 2 seconds.
I expected a bit of a fight between the mirroring and the transfer i.e. RealtimeSync runs every 60 seconds (plus mirror copy time) and tries to make the Slave disk catch up with the Master which puts more load on the Master and could slow down the transfer (this doesn't really bother me).
But what 'appears' to be happening is that the Slave disk doesn't update until the transfer stops (just guessing but; RealtimeSync is waiting 10 seconds for each 'error' it finds and an 'error' appears each time a new file is written?)
RealtimeSync minimum idle time is 60 seconds, FreeFileSync error retry is 5 times with a delay of 2 seconds.
I expected a bit of a fight between the mirroring and the transfer i.e. RealtimeSync runs every 60 seconds (plus mirror copy time) and tries to make the Slave disk catch up with the Master which puts more load on the Master and could slow down the transfer (this doesn't really bother me).
But what 'appears' to be happening is that the Slave disk doesn't update until the transfer stops (just guessing but; RealtimeSync is waiting 10 seconds for each 'error' it finds and an 'error' appears each time a new file is written?)
- Posts: 11
- Joined: 13 Oct 2014
I can confirm that the data was only mirrored after the entire copy procedure finished (RealtimeSync stayed at ~15% processor usage during the entire transfer).
- Posts: 11
- Joined: 13 Oct 2014
Please let me know if this is just how it's going to be (e.g. FreeFileSync and RealtimeSync were never designed or intended to be used how I'm trying to use them) so I can decide to try other options, live with it or wait for a fix of some kind?
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
RealtimeSync and FreeFileSync are independent programs and *currently* there is no data passing between them.
This means at the time when the FreeFileSync ffs_batch job is started by RealtimeSync, latter program has not detected any changes for the duration of "minimal idle time" and FreeFileSync is executing as if manually invoked with no additional assumptions.
Also, while FreeFileSync is executing, RealtimeSync monitoring is disabled and will resume once the sync has finished. So there is no conflict between the two applications.
This means at the time when the FreeFileSync ffs_batch job is started by RealtimeSync, latter program has not detected any changes for the duration of "minimal idle time" and FreeFileSync is executing as if manually invoked with no additional assumptions.
Also, while FreeFileSync is executing, RealtimeSync monitoring is disabled and will resume once the sync has finished. So there is no conflict between the two applications.
- Posts: 11
- Joined: 13 Oct 2014
OK so the 'issue' is with RealtimeSync (the FreeFileSync retries was a bit of a red herring)
i.e. the update that should have been kicked off every 60 seconds (plus mirror time) did not start for >2 hours when copying ~15 GB, so this means that RealtimeSync did not start FreeFileSync until all copying had finished.
I guess I'll just have to investigate other options, obviously there are lots, I'd just hoped that RealtimeSync and FreeFileSync would be a quick easy alternative.
Thanks for the help.
i.e. the update that should have been kicked off every 60 seconds (plus mirror time) did not start for >2 hours when copying ~15 GB, so this means that RealtimeSync did not start FreeFileSync until all copying had finished.
I guess I'll just have to investigate other options, obviously there are lots, I'd just hoped that RealtimeSync and FreeFileSync would be a quick easy alternative.
Thanks for the help.
