Determining When To Sync A File
Files.com uses filename and file size to determine whether a file needs to be synced. It does not currently use information such as modified date or checksum for this purpose.
This methodology works consistently across the wide variety of remote server types Files.com supports.
Checking For Updated File
Syncs with object storage remote servers of type AWS S3, Azure Blob, or Google Cloud Storage include an extra file update check.
The sync checks whether a file has been updated since the sync started. If the file was updated, it is skipped from this sync. This prevents partial files from being delivered to the destination while the source is still being written.
Skipped files are processed again in subsequent syncs.
Known Limitations
The sync strategy works for over 98% of the use cases Files.com has encountered. A few cases exist where Sync does not work well.
Syncing Files to Microsoft SharePoint
Microsoft SharePoint parses files in order to index and promote them within the SharePoint user interface. Files uploaded to a Document Library are modified by SharePoint to include extra column and value metadata. The file size increases and its modification time is updated, which makes Sync unable to determine if the synced file matches the original.
Open Files and 3rd Party File Locks
Open files and 3rd party file locks on remote servers can result in invalid or partial data being synced, or prevent files from being synced.
3play's FTP Server
3play's FTP server reports file sizes incorrectly. Because Sync uses file size to determine whether a file needs to be transferred, syncs against 3play's FTP server produce unexpected outcomes.
Mitigating the Limitations
In these cases, disable Sync and instead use a Remote Server Mount in conjunction with a Copy File or Move File Automation.
If you have a use case where this strategy is not adequate, contact us with the details.