This article provides information about known bugs with the latest release version of SyncBackSE, SyncBackPro, and SyncBackFree:
- There are known problems with the SMB2 protocol support in OS X Mavericks and newer. This means SyncBack may fail when scanning a remote OS X computer. A solution to this problem is to install SyncBack Touch on the OS X computer and create a SyncBackPro/SE profile to use SyncBack Touch (SyncBackFree cannot use SyncBack Touch).
- In some situations all of the available network connections to a server will be used up. See this article for the solution.
- SyncBack only works with valid Windows filenames. This means you cannot have filenames that contain characters such as asterisk, for example. However, starting with SyncBackSE/Pro V5.3 invalid Windows filenames can be used with FTP, FTPS, and SFTP servers. The filename will be translated automatically to make it a valid Windows filename. See the help file for details.
- File hashing (the option "Use slower but more reliable method of file change detection")
does not work correctly when Fast Backups are used. The issue is that
every source file would need to have its hash file computed every time
the profile is run, which would severely impact performance. The hash
value would need to be computed because it would need to be referred to
for comparison when the profile is run in future. This issue can be
resolved by enabling the option "Always use slower but more reliable method of file change detection".
- Stardock WindowBlinds may cause problems with the SyncBack user interface. Please consult Stardock for technical support on such issues.
- eXtraButtons has been reported as causing display corruption and program lockup in some versions of SyncBack. This program apparently has an exception mode whereby SyncBacK can be excluded from their window modification processes, which may solve the issue, otherwise please consult the authors for support.
- In SyncBackSE/Pro V5 and
earlier, when copying over an NTFS blocked file, and versioning is
enabled, the new copy will have the last modification date & time
set to the current date & time. You can resolve this issue by
enabling the "Force the file modification date & time to be correct (may be required when using SAMBA or network drives)" option on the Copy/Delete->Advanced settings page.
To report new bugs please Contact Support