Hi, I’m using TiddlyWiki Classic, which is a file-based wiki that can be served by various servers and apps. Since I’m syncing it with ST, conflicts naturaly happen from time to time. I’d like the server I’m using with TW to detect such conflicts. What options do I have?
I’ve found the API which can be used for events polling (GET /rest/events — Syncthing documentation), but the response descriptioin doesn’t suggest that it’ll indicate if a change lead to a conflict. I can also see an endpoint to get folder errors (/rest/folder-errors-get.html), but the description doesn’t clarify if I can find conflicts this way, and what would be the check for an error to distinguish whether it is a conclict or another error (and if conflicts are considered as errors at all). Can anyone suggest where to look at to implement conflict detection (for a specific file)?
If you listen to file events, LocalIndexUpdated, you can see that it detects the conflict file after creating it – unless it’s ignored by ignore patterns. Otherwise no, there’s no specific event for conflicts.
It would be an idea to add a feature to notify when a conflict files created. I think it is very important. It is very easy to create a script to check for files with conflict name, but I would be much nicer if syncthing does it.
Just walking the filesystem is probably orders of magnitude faster than syncthing being able to query it’s much more complicated database to answer the same question
This is true. However, I think it could be reasonable to fire an event when we resolve a conflict. It could include a little bit more information than is possible to just glean from the resulting file name (e.g., more metadata about the two conflicting versions and which won and why).
That reminds me of Tray Icon for Conflicts · Issue #140 · Martchus/syncthingtray · GitHub. I guess a specific event would be useful for implementing such notifications in Syncthing Tray. (For being able to display an “In conflict” state it would also be necessary to be able to query for conflicts that have already happened and are still present.)
The filesystem is the correct database for that, though, since the conflict may have been detected and resolved somewhere else and the result just synced here…
That’s true. Of course Syncthing Tray is not necessarily running on the same host as Syncthing (like the official GUI) so if I’d ever come to implement a feature for detecting/resolving conflicts on GUI-wrapper-level I need to make its scope clear. Maybe it is also not the best to implement such a feature on GUI-wrapper level in general (as touching the filesystem is normally the concern of Syncthing itself).