Expert Settings
FreeFileSync has a number of special-purpose settings that can only be accessed
by manually opening the global configuration file
GlobalSettings.xml.
Note that this file is read once when FreeFileSync starts and saved again on exit.
Therefore, you should
apply manual changes only while FreeFileSync is not running.
For the portable FreeFileSync variant the file is found in the installation folder,
for local installations go to:
Windows: | %AppData%\FreeFileSync |
Linux: | ~/.config/FreeFileSync |
macOS: | ~/Library/Application Support/FreeFileSync |
<?xml version="1.0" encoding="UTF-8"?>
<FreeFileSync XmlType="GLOBAL">
<General>
<FileTimeTolerance Seconds="2"/>
<RunWithBackgroundPriority Enabled="false"/>
<LockDirectoriesDuringSync Enabled="true"/>
<VerifyCopiedFiles Enabled="false"/>
Contents of GlobalSettings.xml
FileTimeTolerance:
By default file modification times
are allowed to have a 2 second difference while still being
considered equal. This is required by FAT/FAT32 file systems which
store file times only with a 2-second precision.
RunWithBackgroundPriority:
While synchronization is running, other applications that are accessing the same
data locations may experience a noticeable slowdown. Enable this
setting to lower FreeFileSync's resource consumption at the cost of a
slower synchronization speed.
LockDirectoriesDuringSync:
In order to prevent multiple synchronization tasks from reading and writing the same files,
FreeFileSync instances are serialized with lock files (
sync.ffs_lock).
The lock files are only recognized by FreeFileSync and make sure that at most,
a single synchronization is running against a certain folder at a time while
other instances are queued to wait.
This ensures that only consistent sets of files are subject to synchronization.
The primary use case are network synchronization scenarios where
multiple users run FreeFileSync concurrently against a shared network folder.
VerifyCopiedFiles:
If active, FreeFileSync will binary-compare source and target files after
copying and report verification errors. Note that this may double
file copy times and is no guarantee that data has not already been
corrupted prior to copying. Additionally, corruption may be hidden by
deceptively reading valid data from various buffers in the
application and hardware stack:
Does the CopyFile function verify that the data reached its final destination successfully?