I regularly run into the following problem: I have a file (usually .odt) open and edit it, rather frequently. Every time I save the file, a sync conflict gets generated. According to the file name of the sync conflict, the machine in conflict is the same machine that I am editing on. The sync conflict will have the state of the document before my edit.
As far as I understood the rules for syncing and conflict generation, this should not be possible. Am I wrong in that? Or could this behaviour result from some misconfiguration / bad setup?
That indeed shouldn’t happen. Can you describe your Syncthing setup in some more detail (e.g. folder types, ignores, …, or just GUI screenshots)? Can you reproduce with all remote devices paused?
My sycnthing setup is as follows:
I have three laptops, two desktop PCs and a Raspberry Pi syncing give or take a dozen folders (not all folders appear on all devices).
The specific folder it happens in is synced across all devices. It has no ignores setup and is set to send & receive.
I will try to reproduce it with all remote devices paused. However, as the faulty sync conflicts are not showing up reliably (about every 2-3 days), it will take a few days until I can say for sure what the result ist.
One addition to my original post (or should I edit that one?): The bug seems to have a fix daily frequency, by which I mean it either happens continuously on a day or not at all.
Another thing of note: I can only confirm the bug with files edited by LibreOffice (.odt, .doc and the accompanying lock files). I’ll edit the topic accordingly. (EDIT: I apparently can’t edit the original post or the title)
I would have the easy assumption that the Raspi triggers this for performance reasons. Maybe you just set up a connection between Raspi and the computer that is processing the file, and disconnect all others. Then test the editing again and see what happens.
Maybe make for that a extra folder and peer for tests.
If it’s not immediately reproducible pausing all devices likely isn’t practical. An option is to go on as usual and when it happens again, pause remotes and also enable model debug logging.