Conflicts not recognized.

I am a new user to Syncthing. Which I have been really liking. Thanks to the devs! Just today I realized how it deals with conflicts. I’m defining a conflict as when a file has been modified on both machines in the interval between syncs – 60 second default.

Syncthing does not understand the concept of a conflict. It happily writes the newer conflict over top of the older conflict. This behavior is a showstopper for me. It took me a week of happily using syncthing before I realized that this was the behavior. It should never allow data to be overwritten when there is a conflict. I would vote for the Dropbox style solution. Renaming the older conflicted file in place. eg: foo (conflicted 2015-05-14).bar

This is already reported on the tracker last may. #218 #220 #1306

In the meantime this behavior should be documented in the FAQ:

What if there is a conflict?

Syncthing does not recognize conflicts. When a file has been modified on two nodes since the last sync the newer file will be synced over top of the older file.

I agree! As Syncthing is gaining a lot of momentum it should never ever lose a file due to “I expedted it to just rename the file instead of overwrite” - I much prefer to look through list of “conflict-prefixed” files

I hate the idea of having renamed files in the folder. It drove me crazy when using other cloud sync software that would do that. In a development project where you have hundred of files (my work folder that I sync has 188349 files in it).

I used to get problems where to two were offline from each other and changes were made on both (the example that would give the most extreme outcome would be a git checkout on both). Whilst in the environment of a git versioned folder this is fairly easy to resolve it could be used to illustrate the point. With all the sync software I have used I have found that the best resolution is to put the files somewhere else (rather than delete) and prompt the user there was a conflict.

With syncthing I currently have File Versioning enabled on all my folders (Staggered File Versioning on those that change a lot and are more important).

Perhaps there should a (default) versioning option that keeps a backup of conflicted files until the conflict is resolved or possibly after a week from the date that the local user next modifies the file as a fallback.

If there were a conflict resolution area in the GUI I would certainly say it would have to be directory tree based as in one folder at a time (seeing a huge list of conflicted files would never be fun) and with the ability to conflict resolve a whole branch either way. This would be quite complicated though if it were to work effectively. At a minimum it would need to show comparison for size, modified date, and for a more advanced view plaintext comparison of files.

Apparently I may have been incorrect in my assessment of the issue. Syncthing doesn’t even pick the newer file when a conflict exists. It chooses one or the other randomly.

As frequent contributor AudriusButkevicius says here “At the point two files get modified on two machines without the other machine being aware of it, it’s nondeterministic which file will win. There already is a issue in the tracker about conflict resolution.”

This is crazy behavior in a syncing app. There should be some mention of this in the FAQ and a warning on first install.

Added to FAQ: Thanks,

From the FAQ: "When a file has been modified on two nodes since the last sync the newer file will be synced over top of the older file. "

Is it true that it takes the newer version? Is the AudriusButkevicius comment quoted above incorrect? It would be better of course. if it behaved consistently it could more easily be dealt with. (at least emotionally :smiley: )

Unfortunately versioning is no real solution unless you recognize that data has been lost. In a multi user environment where many files are changed constantly this doesn’t seem like the right solution for me.

On a positive note I really appreciate the small footprint and how cross platform the app is and the web UI makes for a consistent experience compared to other apps I’ve tried.

Updated the FAQ to reflect this.

Indeed. You probably want a version control system, or a centralized file server with locking (and a version control system).

But the conflict situation should be rectified at some point.

Post is moved here…

click to read full post containing ideas for FS Tree revision