FreeFileSync Open Source File Synchronization

About Tutorials Screenshots Vision Download Archive Forum F.A.Q. Manual Donate
It looks like an ad blocker has blocked the ads. The FreeFileSync project is 100% dependent on ad revenue and donations to stay alive. Instead of the ads, and after FreeFileSync has proven useful to you, please think about supporting with a donation.
FreeFileSync User Manual:

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">
        <FileTimeTolerance Seconds="2"/>
        <RunWithBackgroundPriority Enabled="false"/>
        <LockDirectoriesDuringSync Enabled="true"/>
        <VerifyCopiedFiles Enabled="false"/>
Contents of GlobalSettings.xml

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.

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.

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.

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?