I was just reading about not syncing conflicts of conflicts on GitHub and it made me think. Why does syncthing creates conflicts in the first place? Wouldn’t it be better just to list conflicts in GUI and not to create any extra files?
I’d personally rather have not synced files than plenty of .conflict files and then have to sort it all out.
Possible? Or not 
Not syncing files would go against Syncthing’s base principle of syncing files.
Haha;) define syncing, or “in sync”. Conflict is not sync. I’m not saying not to sync, just thinking out loud what is the benefit of having conflicts on nodes as opposed keeping their own versions and reporting conflicts only via GUI. If I’d have 100 conflict files to manually resolve I think I’d rather not have them in the first place. With GUI you can see what files are problematic and then you can take corrections without dealing with extra files. Hm?
Well, with the current setup you don’t need to do any manual resolving; it’s already done for you. There might be a need to do a manual cleanup of the losing files (i.e. the ones that were renamed to …-sync-conflict-…). I could see an argument for automatically cleaning out old conflict files, as an addition to the current way of limiting the number of them.
1 Like
Yeah. Autoclean. Better than manual;)
No, not really. Automatically deleting one version of the file, which may be the version I want? No thanks.
I don’t think that’s an argument against being able to configure an optional cleanup though, with a two week threshold or something.
Well, @calmh is saying that conflicts are resolved automatically so keeping nodes in sync. Why to keep out of sync version? If everything went well in the first place there wouldn’t be any conflict anyway, right?
If there wasn’t a conflict, you didn’t get a conflict copy. You got the conflict copy because there were conflicting modification to the file; for example you changed it, and someone else changed it at the same time. Either or both versions may be valid and valuable, which is why we keep both. But at the same time we did decide that one is better than the other (a little arbitrarily), so I can see an argument for cleaning out the other version at some point.
Of course, on Unixes this is quite trivial already. In cron:
# delete conflict copies older than two weeks
find /path/to/folder -name \*.sync-conflict-\* -mtime +14 -delete
Not tested, may eat your files, tread carefully.
Yes, conflicts are resolved automatically, but they may not be resolved correctly. It takes human interaction to make sure that the correct version of the file is kept.
Yes, it may be good to automatically delete old conflicts, but not before the user has had a chance to inspect them!
1 Like
Ah ok. Got it. A question though. Except of creating a conflict file, is there another means of telling user that conflict happened? I’m thinking- do I want to search for “syncthing.conflict” or do I want to see it in a log or GUI?
No other mechanism currently. See also:
Read it, I accept the current setup but I’m not convinced
You’re saying if there is a conflict, syncthing will somehow pick one file and that’s a winner. And then just to make things safe, it creates a copy so user can check if the winner was indeed the proper one.
So what is good about that? Isn’t it better to keep both revisions as they are and just announce the conflict? Maybe with an option to select on node “sync this one please” and problem solved?
In this scenario I’d have to manually check files in conflict and select a winner. Well isn’t it better than picking winner automatically and creating backups for user to check later and pick a winner if necessary?
How would you select a winner if we didn’t download it for you to look at? As long as we’re doing that, one of the files should be at the original filename and the other can’t be.
Ok. Now I’m convinced;) I didn’t think of syncthing being the only tool to see the repo. If user can’t i.e. ftp to manually compare files, then what you’re doing is probably the best way.
But I’d say it all depends on the setup. If multiple users are changing the same file at the same time, they still have to somehow communicate and exchange that info and pick a winner. (Or even merge files)
So even “my way” userA can call userB and have a chat which file is winner.
There is always a manual interaction involved. It is only the way how conflicts are handled. And I’d say there can be multiple ways how to do it.