A profile can be configured to watch for changes to files, and when any changes are made, the profile will be run. There are some important points to keep in mind:
2.If you make changes to those files while SyncBack is not running it will not detect them and so when you start SyncBack it will not run the profile. Because of this you may still want to schedule the profile to run periodically.
3.Changes cannot be detected on FTP, email servers, MTP, Touch or cloud servers. It will probably also fail to detect changes on NAS devices that are not running Windows (many NAS devices use a version of Linux) and on networked drives that are not running Windows.
Instead of detecting changes in files, you may want to have the profile run when a program closes. For example, if you are editing files then you may instead want SyncBack to backup the files as soon as you close the editor software. Having SyncBack backup files every time they are changed may not be practical in some cases.
•Run this profile when any files or directories are changed on source: If this option is enabled then the source/left folder will be watched, and if any changes are made to any files (including files in sub-folders), or if any files are deleted, then the profile will be run.
•Run this profile when any files or directories are changed on destination: As per the above setting but the destination/right is watched. If you using a backup profile then there is no point watching the destination for changes. Also note this option is not available with Fast Backup profiles.
•Run interactively, i.e. prompt me if required: If a profile is run when changes to the files are made, by default it is run unattended, i.e. dialog box and prompts related to the profile will not be displayed. If this option is ticked then you will be prompted as and when required.
•Wait a number of seconds for no changes before running the profile: A common problem with running a profile when files are changed is that there is no way for SyncBack to know when a program has finished writing to or updating a file. For example, a video editing program may take several seconds to save the changes you've made to a video. In that case SyncBack will run once it sees the video file being updated, but the video editing program may not have finished saving the file before SyncBack starts copying that file. To avoid these kinds of problems you can configure SyncBack to not start the profile until there have been no changes for a certain number of seconds. For example, a program may need to update many files before it exits. Updating all those files may take several seconds. Let's say you set this profile setting to 5 seconds. If the program updates one file then SyncBack will see the change but won't yet run the profile. The program may then update another file a couple of seconds later. SyncBack will detect the change but still won't run the profile because changes were made less than 5 seconds after the previous change. Once the program has saved all its files, and 5 seconds have passed without any file updates, SyncBack will then run the profile. The following setting defines if the seconds to wait is idle seconds.
•This must be idle computer time: If enabled then the number of seconds specified in the above setting refers to idle time. For example, if you've specified to wait 5 seconds, and this option is enabled, then SyncBack will wait until the computer has been idle for that number of seconds after any changes are detected. Idle time is the amount of time that the keyboard, mouse and any other input device has not been used. This setting is useful to make sure profiles are not run while you are using the computer.
Important: this delay starts from the last alert by Windows of a change (and is reset/zeroed by any fresh alert). But if the delay is set to 5 seconds, for example, and the last alert by Windows of a change was 5 seconds ago, the profile will then start. If that last change is still ongoing (video program is still writing after 5 seconds) then an error may occur as the file is still being written to. It is recommended that you set the delay time to exceed the duration of the slowest/longest change-event anticipated.
•Queue Profile: If this option is enabled, the profile will not be executed immediately and will instead be added to the queue.
If you are using versioning then you should set the profile to store versions in a sub-folder of the base folder and not in a sub-folder of the original file. This is not only because it will cause change events to happen but if you are running a synchronization profile then you will get unexpected results for "dead" folders, i.e. folders that only exist because they contain versions.
Why is my profile being run?
A common complaint is that SyncBack is running a profile even when the user believes it should not. This is usually because a new file has been created, or deleted, in a folder. Often these are temporary files, e.g. Microsoft Office files that start with ~$. When this happens, Windows tells SyncBack that a folder has changed. It does not indicate which file has been deleted or created, only that the contents of a folder has changed. If that folder is part of the profile then SyncBack has no choice but to run the profile as new files (or even folders) have been created or deleted, and it cannot know which unless it runs the profile to find out.
If SyncBack is not being notified, by Windows, of changes then there is a way to discover why:
•First, you must configure SyncBack to record errors in the Windows Event Log. To do this, start SyncBack and go to Global Settings in the burger menu then the Expert tab. Enable the option Use the Window Event Log and click OK.
•Now make some changes to the folders that are to be watched for changes
•Open the Windows Event Viewer (how to start it depends on the version of Windows being used, but typically it's in the Administrative Tools section of the Control Panel).
•In the Event Viewer tree (on the left) navigate to Event Viewer (local) -> Applications and Services Logs -> SyncBackPro
•Look for entries that are prefixed with MonitorErrorCallback in the error text (on the General tab).
All Content: 2BrightSparks Pte Ltd © 2003-2021