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. 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. File hashing (the option " Use slower but more reliable method of file change detection") does not work correctly when Fast Backups are used. The filename will be translated automatically to make it a valid Windows filename. However, invalid Windows filenames can be used with FTP, FTPS, and SFTP servers. This means you cannot have filenames that contain characters such as asterisk, for example. SyncBack only works with valid Windows filenames. In some situations all of the available network connections to a server will be used up. The folder will be deleted (after the copy has failed) so the second run of the profile will not have a problem (as the folder has already been deleted). New folders are created as needed as files are copied. This is because SyncBack creates and deletes folders after files have been copied and deleted. Mirroring a file will fail on the first run if a folder with the same name already exists in the destination (even if the folder is configured to be deleted).
Before doing so, first check to see if there is a beta version available which fixes your issue. To report new bugs please Contact Support.
This article provides information about known bugs with the latest release version of SyncBackPro, SyncBackSE and SyncBackFree.
Modified on: Fri, 17 Jul, 2020 at 3:24 PM Solution home Technical Articles Common Questions and Solutions Known bugs and problems with SyncBack
0 kommentar(er)
