Hello again!
We are using the "automatic" mode in our sync solution and that is working very well overall. We are also including users over VPN who are syncing with the backup server on site, and while that works very well, the first part of the scanning process does seem to take a long time.
As FreeFileSync discovers, or looks for, each folder pair, there is a noticeable pause before it moves on to the next folder pair, where it looks like FreeFileSync is locking the directory (I assume by writing the ffs_lock file?). We also have had some reports of Windows reporting a delayed write failure for this file when the user logs back in again, so I had a quick look at our globalsettings.xml.
The value for LockDirectoriesDuringSync is set for "true", and if I change this to "false" the entire process does seem to be noticeably faster.
What is the benefit of locking the directory vs not locking during a sync? Is there some specific risk of data loss or file overwrites and to be safe we need to have that set to true?
What happens if we set that to "false"? What risk are we taking if we set LockDirectoriesDuringSync to "false" in order to gain back some performance during the initial scan?
Benefit and function of the global setting "LockDirectoriesDuringSync"
- Posts: 74
- Joined: 17 Mar 2008
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
The locking file behaves like a mutex to protect from race-conditions that occur when multiple FFS processes are accessing the same directory. The standard definition of race-conditon also applies here: "multiple accesses at least one of which is a write".
So in case you can guarantee by some external means that there never can be a race-condition (e.g. you know you are the only user at a time, or there are multiple users but they only read from a directory), then you may safely disable the directory locking.
The following objects are shared between multiple FFS instances and thous need to be protected by a mutex:
- the sync.ffs_db file: two FFS processes may interfere when saving this file at the same time
- single files: if one FFS instance is currently writing a file, while another FFS instance tries to copy it, it would first receive a sharing violation, but if global settings: VSS is active, it would still copy the file effectively corrupting the target file with an incomplete version of the source file. Note that this cannot happen if global settings: fail-safe file copy is active: In this case the second FFS instance would only try to delete the alleged orphan .ffs_tmp file and fail, because it is still open.
- directory structure: if files are updated by one FFS instance after another FFS instance had already scanned the directory, this invalidates this view. This is probably not the most serious problem since FFS is designed to expect changes after comparison in general and handles them gracefully (if only by reporting lots of errors).
So in case you can guarantee by some external means that there never can be a race-condition (e.g. you know you are the only user at a time, or there are multiple users but they only read from a directory), then you may safely disable the directory locking.
The following objects are shared between multiple FFS instances and thous need to be protected by a mutex:
- the sync.ffs_db file: two FFS processes may interfere when saving this file at the same time
- single files: if one FFS instance is currently writing a file, while another FFS instance tries to copy it, it would first receive a sharing violation, but if global settings: VSS is active, it would still copy the file effectively corrupting the target file with an incomplete version of the source file. Note that this cannot happen if global settings: fail-safe file copy is active: In this case the second FFS instance would only try to delete the alleged orphan .ffs_tmp file and fail, because it is still open.
- directory structure: if files are updated by one FFS instance after another FFS instance had already scanned the directory, this invalidates this view. This is probably not the most serious problem since FFS is designed to expect changes after comparison in general and handles them gracefully (if only by reporting lots of errors).
- Posts: 74
- Joined: 17 Mar 2008
Thank you again, I think it makes sense for us to keep the lock in place because we are in fact going to have people with more than one machine running FFS at the same time. Even though it might exact a small performance penalty, it seems the safer route.
