Jakob, thank you for a specific request I can try to answer. Here is my first attempt to document a rule-set a receive-only folder should implement. I believe delete, modify, and create can all be captured in the concept of “change”, so I did not repeat the same thing three times.
Imagine three peers are in the sync group, each with a different character. All three types don’t need to be present, this only documents what they should do ~if~ they were present.
SR = normal send & receive folder SO = existing send-only folder type RO = proposed receive-only folder type
Starting from a fully synchronized set of peers, there are only three things that can happen. Here is how Syncthing should respond to those three events. Note SR and SO behavior is the same as what Syncthing already does.
-
change SR. Propagate changes to RO. SO shows override GUI button; if pressed, change is undone on SR and RO and button goes away.
-
change SO. Propagate change to RO and SR.
-
change RO. SO and RO show override GUI buttons; if either is pressed change is undone on RO and both GUI buttons go away.
Please tell me what condition or edge case is not considered above and I will try to explain the hoped-for behavior.
It seems that any visible GUI override button is a temporary state. A user ~could~ leave it there indefinitely, but like Syncthing already does, it is incumbent on the admin user to either fix the discrepancy manually, or press the override button to fix the discrepancy, or live with the override button on the GUI.
Thanks for asking a question where at least I can feel I’m contributing to a solution. I wish I was an expert GO programmer!