This problem usually occurs when using Internet Protocols such as FTP, WebDAV, as well as some cloud services such as Amazon S3 and Rackspace Files. The problem does not occur with Windows networking (CIFS/Samba), SSH/SFTP, and many modern FTP or even some WebDAV servers. Modern cloud services such as Google Drive, DropBox, Box, Backblaze B2 and others are also not affected.
If you do see modification timestamp issues when copying within the local area network, please update Syncovery to the latest version. If this doesn’t help, please edit your profile and go to the tab sheet “Special”->”More” and choose:
Double-Check Each File's Destination Timestamp After Copying.
FTP and WebDAV servers traditionally use the current system time for all incoming files. So the timestamp on the FTP server becomes different from the Last Modified time on your computer. In some cases, this is not a problem (for example if you only copy files to the FTP server). However, if you need to copy bidirectionally or really need to preserve the timestamp, here’s what can be done.
The best thing to do would be to install a more modern FTP server software that allows setting the timestamps, or switching to a different protocol, such as SSH/SFTP.
If the server software can’t be replaced, you could use Filename Encoding to retain the timestamps on the FTP server. You’ll find that option on the Versioning tab sheet. Filename Encoding will modify the filenames by adding the date and time to them, so you can only use it if it’s OK that the filenames look encoded on the server.
If filename encoding can’t be used and you need to do a bidirectional synchronization, there is still another option. You can use SmartTracking, which can remember the timestamp that the server assigns to the files when they were uploaded. That way, it can recognize if the files have been changed or not, even if the timestamp is not identical to the one on your computer. For this, please choose the SmartTracking operating mode on click the Configure button. Go to the Options tab sheet and choose “Detect Unchanged Files” for the online side. Uncheck the other option “Also Ignore File Sizes Being Modified”, which is rarely needed. It can however be useful for Sharepoint sites, which frequently add metadata to incoming Office documents, thereby changing the file sizes.
If you have already uploaded files and their timestamps do not match, you can use this SmartTracking method (as described above) to handle the problem. First you need to let the program build the database so that it remembers the existing timestamps. Do this by starting the profile manually and choosing “Show: Unaffected” in the Sync Preview so that it doesn’t copy any files but adds them all to the database.