It’s the Recent changes button in the web ui.
The fact that you saving the files in one place doesn’t necessarily mean that other computers are not opening those files as they get downloaded and for example generating thumbnails, or adding some metadata to the files. If all other 3 are doing that, it explains the conflicts.
You can diff the files to see what has actually changed, which perhaps can help you make some conclusions.
Sorry for interruping, but if “useLargeBlocks” can cause this bad effect, can you add a reminder in Syncthing, like “Other side using useLargeBlocks, Press yes to enable it on your side”?
I also saw some conflicts for files that were only changed on one side and synced to some other devices (not sure when it started, could be 0.14.48), no large blocks enabled here. Did not have time to investigate what the contents are (deleted conflicts and pressed save again because I had the file open).
All that share the folder are Linux with ext4 (Ubuntu 18.04, Ubuntu 16.04 and Raspbian stretch) - there are other windows devices that I use, but none has this folder. One thing that is probably worth mentioning is that the files where this happened were modified often and quickly with filesystem watcher enabled (multiple modifications before the slow raspberry pi finished syncing).
I just reproduced “this” and it is already fixed in master (i.e. will be fixed in 0.14.50). In quotation marks because obviously I can’t be sure it is the same issue, but I found “a” issue that only exists since 0.14.48 and can lead to erroneous conflict copies:
Initial state: Two devices A and B with a file F that was previously modified on both devices, i.e. the version vector must include both IDs. For easy reproduction, disable watch for changes and use a high scan interval on A (you don’t need to interact with B).
In A’s UI, pause device B.
Add random data to F and scan it.
Again add random data to F, but do not scan it.
Unpause device B.
Actual: Conflict copy is created.
Expected: Just update the file, it was only changed on A.
This fits with the descriptions that this happens with files that are often changed. The problem was introduced in https://github.com/syncthing/syncthing/pull/4767 due to changed but valid files being marked as invalid on request -> conflict. https://github.com/syncthing/syncthing/pull/4952 already fixes this issue by discerning between different types of invalid files and not conflicting files, that were marked to be rescanned.
@VaclavC, @Alex Please report back if this issue still persists in v0.14.50.
Just to add my few cents: I’m also facing this issue quite a lot recently (probably since v0.14.48)
no paused devices or folders, useLargeBlocks is off,
file watcher is enabled
While saving a file frequently on device A (i.e writing a document/text file), conflicts get created locally a lot, with the self-ID (A’s ID) appended.
On other devices the file in question was never modified, in a sense that - it’s A that created a “conflict with itself”, and no “real conflict” occurred.
Came to report the same thing - lot’s of conflicts caused by one-sided modification, especially during git checkout (ie. a quick change scenario).
I’m glad to find this thread and will be waiting for the 14.50 now. Are there any tips how to avoid this effect for now?
No real patent solution I think. If it is an option for you, you could disable watch for changes and put the rescan interval to something longer than the interval you are continuously changing a file (e.g. longer than what you need to edit a photo). Thus you increase the chance that the change info will only be sent to the remote after the file is in its final state -> no conflict.
As of now 0.14.50 is at least 1.5 months away at the moment, and this bug turns out to be quite a PITA, with 10s of conflict to clean up pretty much on a daily basis.