File Sync - How It Works
The File Sync feature is composed of three main components.
Cloud Storage
The File Sync needs a storage location for all the 'master' files. It is to this storage location files are synchronized to and from. The storage location can be on a local network, server instance or service from any web service provider such as Amazon, Goole, Azure, etc. The location is set up in the Service Configuration Tool by an administrator or company IT department.
Local Storage
Each user has predefined paths to their IMPACT locations set in the Server Connect software. A small file will be placed inside the root folder of each project on its hard drive. This file has information about what was synchronized and when on the user's PC. Do not modify this file.
User Interface
The synchronization interface is a simple dialog that appears the same throughout the different applications. Files are automatically categorized by status and assigned a default action. Typically, these settings are left untouched, but a user can always override the system if needed. Here is how you use it.
File status while checking files on the cloud:
In sync:
This indicates that the file on the cloud and on the local disk is the same.
Newer version on disk:
This indicates that the file on the cloud and local disk differs. And the latest version of the file is on the local disk. This happens when a user did modification to the local file and not updated (or synchronized) the file on cloud.
Newer version in cloud:
This indicates that the file on the cloud and local disk differs. And the file on the cloud is the latest one. This happens when user A has modified the file and then synchronized it with the cloud. Now for user B, there will be the latest version of the file on the cloud. In this case user B should download the latest file from the cloud.
Newer version on both filesystems:
This happens when user A has modified the file and did not synchronize it with the cloud. And user B has modified the file and then synchronized it with the cloud. Now for user A, there will be a newer version of the file on local as well as on the cloud. But this is rare because now before editing it is mandatory to lock the file. So, another user knows that the file is locked hence not allowed to edit. And on Unlock we are automatically synchronizing the files with the cloud.
New file on disk:
As the name suggests, this means the user has just created a new file and not yet uploaded it on the cloud.
New file in cloud:
This means user A has created a new file and uploaded it on the cloud. Now for user B, there will be a new file on the cloud.
Deleted on disk:
When the user has deleted a local file.
Deleted in cloud:
When the file is deleted from the cloud. (Note: The file is not deleted from the file storage but it's marked as deleted in the SQL Database)
Deleted on both filesystems:
If the file is deleted on the cloud and also deleted locally
Differ on both filesystems:
This means that the version for the file in the Local DB, File that should be synced and the version in the SQL DB all differ. Then does IMPACT not know what version is the correct one and therefore does IMPACT not know what to do. It's possible to use "Download Cloud File" and compare the cloud file and the local file to see if the user should upload or download the file.
Locked by another user:
If file is locked by another user. (This require that the file have been locally mortified outside of IMPACT)
In use by another program:
If the file is already open in another application.
File Sync Log & Validation:
Project manager 16.0.020 & Service configuration 16.0.020 introduces a log file for the file sync. The log file is located in the "Appdata -> Local" and is named "CloudFileSync_X_X_XXXX.log" - The X_X_XXXX is the date of the creation date of the log file.
The log file contains the action of the file sync and also the "Checksum" of the file that is up- or downloaded. The "checksum" is what IMPACT uses (Along with file size and timestamp) to validate what file is the newest or if the file is in sync.
Example from the log file:
There have also been implemented a validation for the files that are up- or downloaded to make sure that the file that is up- or downloaded. This validation will only be logged if the validation failes.
Example of how the validation works:
If we have a file newly created by user1 - In this case file should be uploaded on the cloud so in File Sync we upload this file using the cloud service provider's API. Now after this upload is done on the cloud. We have added validation for file content (i.e checksum) - In this validation, we again read the file content from the cloud server and calculate its checksum, and then compare this checksum with the one which we already have. If it does not match, we upload the file on the cloud again. This validation happens 2 times. If this validation is successful then only we update the checksum information in DB.
Now suppose user2 tries to sync this file. In this case, the file should be downloaded on his/her local disk. We use Cloud API to download the file and store it locally. After this is done, the validation is added where we again download/read the file data from cloud server and then check its checksum with the one we have downloaded. If it matches, then we update the DB. If it does not match, we try 2 times.
But even if the download or update fails after 1+2 trials, we still update the DB files. But in that case, we have a log added which will give us details if there is a mismatch in the file checksum.