Use checksums before creating conflict file

[MTRichards]

We have another case where the storage on a sync client desktop has caused the mtime of a few of the files to change. This change has then led to all of these files be re-downloaded from the server, and in addition client side files becoming conflict files on the desktop, despite none of the files having changed.

Can we use a checksum before we download a file or create a conflict file, to ensure at the last minute that this file is indeed new and different than what is already there?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32036498-use-checksums-before-creating-conflict-file?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github).

[dragotin]

What you describe could only have happened if the files were changed on the server and had the mtime shift on the client at the same time. That would result in the conflict. However, why did the server change not change the actual file? Are we sure about the root cause of this?

About the feature ideas: We can only avoid the download if the server provides content checksums for the files. New clients will upload checksums with all uploads (#4532) and the server returns them IF they were uploaded before and the file did not change on the server.

#2983 and #4375 is about using the checksums to improve conflict file creation and rename detection on client side. @ckamm FYI.

Also note that we do it already since version 2.1.0 for .eml files: #3235

Note that this features are optional as long as the server does not calculate checksums for files that do not have them from a previous upload, or have changed.

[guruz]

In addition to what @dragotin said: Checking if the downloaded file differs to the local file we do already since more than a year.

[dragotin]

Oh yes, by a byte-by-byte comparison, completely without this modern checksum crap ;-)

[MTRichards]

The root cause here was a filesystem problem, most likely, and then a server side backup / restore (maybe). This was s3 and msrex. Let's discuss live at some point next week, so he can demonstrate what is happening and we can dig in.

[guruz]

@ogoffart I remember we're doing this now already? maybe I mix it up with the did-it-actually-change check though..

[ckamm]

This should be covered by the improvements to download-prevention. In short, we skip the download if the remote checksum matches the local checksum (as well as some other criteria). And since e694ffc we will also skip the download in that case even if the local mtime was modified.

That means this issue should be resolved for 2.4.0.