When SyncBack is accessing files on a supported cloud storage or (S)FTP server it relies on a certain, predefined set of commands that the server can understand and execute. In other words, SyncBack cannot do as it wishes (meaning accessing and modifying content) without going through the cloud/FTP server, which acts as a middleman.
For example, if SyncBackPro needs to upload a file to Dropbox then it must first authenticate itself. To do this, SyncBackPro needs to provide login details to Dropbox so it can access the files on Dropbox on the users behalf. The user has already configured the profile in SyncBackPro so it can access their files. If the user did not do this then SyncBackPro cannot access their files. This is basic security. Once SyncBackPro has been allowed to connect to Dropbox, and access the users files, it then needs to ask Dropbox to perform file operations on its behalf.
It is imperative to understand that there is absolutely no way for SyncBack to access any files stored on a cloud/FTP server without going through the server itself via a properly defined set of instructions. If, for any reason, the server rejects SyncBack’s request to access folders/files then there is nothing much left to do. SyncBackPro does not have direct access to the files, i.e. it cannot bypass the cloud/FTP server.
If you are using a cloud storage’s native sync application, e.g. OneDrive, Dropbox, Google Drive etc., you may notice performance differences when comparing to SyncBackPro. This happens because the native sync applications leverage on features that are not available to third party applications, such as SyncBackPro, giving them a performance advantage when it comes to some features.
When accessing files on a remote storage system, like the cloud and FTP, SyncBack does not have direct access the files. It must ask use the remote storage system to access those files on its behalf. There is no way to bypass the server and get unrestricted access directly to the files.