When something does not happen as expected

The first place to look is always the log. At level Info it records what was copied and deleted; at Debug also which file was skipped for what reason.

A file is not copied

• It is empty. Files of size 0 are skipped as long as Synchronise empty files is not set. The log notes “The empty source file was not copied”.
• The wildcard does not match, or an exclusion applies, see Setting up synchronisations.
• The target is newer than the source. Without Copy even if the target file is newer it stays untouched.
• Source and target count as equal. If files are compared by Time only, a change of content without a new modification time goes unnoticed. In that case also switch on Size or Content.
• The synchronisation is not active – the Synchronisation active tick is missing.
• It is a subdirectory, but the synchronisation is of the type Directory. Subdirectories need the type Directory tree.

Files are copied again on every run although they are unchanged

The target stores the modification time more coarsely than the source, an NTFS or FAT disk as the target of a Linux disk, for example. The copy is then fractions of a second ahead of its original, and when comparing by Time the source counts as newer. The Tolerance in seconds on the Options tab catches this; it is at 0 if someone switched it off. A jump of exactly one hour on all files points to FAT after a change of summer or winter time, see there.

Nothing is deleted in the target although the option is set

• The source cannot be reached. An unplugged drive, a share that is not connected or an SSH server that cannot be reached mean that nothing at all is deleted. This is intended.
• The type is File. The option applies to Directory and Directory tree only.
• Wildcard or exclusion take the file out of the synchronisation – then it is not deleted either.
• It is about a directory. Files are mirrored; a directory deleted in the source stays in the target.

Nothing is synchronised at all

• Is the background service running? Service and program do not synchronise at the same time.
• If Start and Synchronise once are greyed out, the configuration holds no synchronisation that can be run – because all are inactive, or source and target are missing, for example.
• Was the configuration saved after the last change?
• With source or target over SSH: does the other end answer? AutoFileSync checks this before every run and leaves the synchronisation out as long as the server cannot be reached or the login fails. The log then says “SSH path not reachable” with the reason.
• The server is back, but still nothing happens. The result of the reachability check is cached, so that not every run opens a new connection. After a failed attempt it is checked again after a few seconds at the earliest, during a lasting failure at most every five minutes. It can therefore take up to five minutes until a restored connection is noticed.

An SSH connection fails

• Authentication error – user name or password are wrong, or the server does not allow logging in with a password.
• Connection error – host or port cannot be reached.
• The host key has changed – the server identifies itself with a different key than the first time. AutoFileSync then aborts. If the change can be explained, after reinstalling the server for example, the old entry must be removed from the file known_hosts in your user profile.
• SSH account not found – the name before the colon in the path belongs to no connection that has been set up. This happens when a connection was renamed, for example; the synchronisations concerned then still point to the old name.

In all these cases the synchronisation concerned is skipped for this run: nothing is copied or deleted. The other synchronisations go on as usual.

A warning about a missing drive appears – or stays away

Whether an unreachable source or target is reported is decided per synchronisation by the option Warn if the drive or SSH connection is missing: switched on, there is a warning after Synchronise once and a warning line in the log, switched off only an info line. So if one synchronisation warns and another does not although both miss the same disk, the option is set differently on them. Everything else is under Unreachable drives and connections.

Bringing back deleted files

If the delete mode is set to Move to recycle bin, the files are in the recycle bin directory set there, in the structure of the place they came from. With Delete permanently and with targets over SSH there is no such copy.

If a target file was overwritten, the Generation principle helps – provided it was switched on beforehand: the previous version is then next to the file as .bak.1.