The Options tab in the dialog of a synchronisation sets what source and target are compared by and what happens in the special cases.
These three ticks decide how AutoFileSync recognises a difference. They can be combined.
| Criterion | Meaning |
|---|---|
| Time | The modification time decides. This is the usual case and by far the fastest. |
| Size | Different file sizes count as a difference. |
| Content | The files are compared by their content. This is exact, but costs reading time on both sides. With two-way synchronisation the modification time additionally decides which side is the newer one – a comparison by content alone cannot tell. |
| Tolerance in seconds | Two modification times at most this many seconds apart count as equal. The field is only active while comparing by Time is switched on; the default is 2 seconds, see Tolerance and file systems. |
When copying, AutoFileSync takes over the modification time of the source, but the target stores it only as precisely as its file system allows. Without a tolerance the source would then be fractions of a second newer than its own copy on every run and would be copied again and again. The tolerance must be at least as large as the coarsest time step on either side:
| File system | Precision of the modification time | Tolerance needed |
|---|---|---|
| ext4, Btrfs, XFS, APFS | nanoseconds | 0 s |
| NTFS | 100 nanoseconds | 1 s |
| exFAT | 10 milliseconds | 1 s |
| HFS+, SFTP servers | whole seconds | 1 s |
| FAT32, FAT16 (USB sticks, memory cards) | 2 seconds | 2 s |
The default of 2 seconds covers all of these cases. FAT also stores the time as local time: after a change between summer and winter time all files appear shifted by one hour. To avoid that, set the tolerance to 3600 seconds for a while or also compare by Size.
The other side of the tolerance: if a file is saved again within the tolerance after its previous change, and a run happened in between, the second change is noticed only with the next save. If you edit files in quick succession, it is best to also switch on Size, or to set the tolerance to 0 if both sides store the time equally precisely.
| Option | Effect |
|---|---|
| Delete the source after copying | After a successful copy the source file is removed – into the recycle bin or permanently, depending on the delete mode. This turns a synchronisation into a move. For sources reached over SSH the option has no effect. Together with this option, Two-way synchronisation and Also delete deleted files in the target are disabled: the one would copy the moved files back, the other would delete them in the target again. |
| Two-way synchronisation | The opposite direction counts as well: what exists only in the target is copied back into the source, and a newer target wins against an older source. Together with Also delete deleted files in the target, deleting wins – setting both at once rarely makes sense. The option excludes Delete the source after copying and Copy even if the target file is newer; whichever is set first disables the other. |
| Copy even if the target file is newer | Normally AutoFileSync does not overwrite a target file that is newer than the source. With this option it does. With two-way synchronisation switched on the option is disabled, because it makes no sense there. It is also disabled while neither Time nor Size is compared, because only those criteria can find a target newer than the source. |
| Generation principle | Before an existing target file is overwritten, AutoFileSync renames it: report.doc becomes report.doc.bak.1, the next time .bak.2 and so on. Older versions are kept this way. Note that these backups stay in the target and take up space – they are not cleaned up automatically. |
| Also delete deleted files in the target | A file that exists only in the target any more is deleted there – the target becomes a mirror of the source. Details and limits are in the section below. For the type File and together with Delete the source after copying the option is disabled. |
| Backup proof | Every run that copied something or ran into an error writes an entry into a proof file; see Backup proof. |
| Synchronise empty files | Files of size 0 are normally skipped: an empty file is more often an interrupted write than a file meant to be empty, and copying it over a filled target file would lose data. With this option they are included – meant for placeholders such as .gitkeep and for lock and marker files. Caution: if the source file is empty and the target file is not, the synchronisation then replaces the target's content with the empty file. |
| Warn if the drive or SSH connection is missing | When the source or the target cannot be reached – an unplugged drive, a share that is not connected, an SSH server that does not answer – the synchronisation is skipped; nothing is copied and nothing is deleted. That is not an error. With this option (default: on) "Synchronise once" reports the skip as a warning, and the log holds a warning. For a backup disk that is plugged in only now and then, switch the option off: the absence is then only noted in the log. In detail: Unreachable drives and connections. |
| Seconds of pause | Waiting time between two runs of a continuous synchronisation, adjustable from 1 to 60 seconds. Short pauses notice changes sooner and put more load on drives and network. |
This option deserves a closer description, because it is the only one that removes data in the target.
If the option does not take effect although it is set, When something does not happen as expected helps further.