Expert Settings
FreeFileSync includes several special 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
only apply manual changes when FreeFileSync is not running.
For the portable FreeFileSync variant, the file is located 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 a 2-second difference and still considered equal.
This is required by FAT/FAT32 file systems which store file times only with a 2-second precision.
RunWithBackgroundPriority:
When synchronization is running, other applications accessing the same data locations may experience noticeable slowdowns.
Enable this setting to lower FreeFileSync's file access priority at the cost of a
slower synchronization speed.
LockDirectoriesDuringSync:
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 recognized only by FreeFileSync,
ensuring that at most one synchronization runs for a folder at a time, while other instances are queued.
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:
When active, FreeFileSync will binary compare source and target files after copying and report verification errors.
Note that this may double file copy times and does not guarantee that data was not already corrupted before copying.
Also, corruption may be hidden by reading valid data from various buffers in the application or hardware stack:
Does the CopyFile function verify that the data reached its final destination successfully?