Device A shares a receive-only folder with devices B and C, everything is in sync and C is not connected currently.
Device B changes file F, it syncs to A.
Device C changes the same file F and then connects.
Result: A sees the conflicting change to F by C and resolves it, creating a conflict copy, which gets the receive-only flag, thus isn’t propagated to B and C.
I would argue that this is not a local change and thus shouldn’t get the flag.
Solving it is tricky though: Currently we just create the conflict file and schedule it for scanning. Either the scanner needs to gain knowledge on conflicts or we directly add the the conflict to the db in the puller. I believe the latter should be easier.
I think this is convoluting things. If you want to send conflicts to others, have a send receive folder and control local writability with filesystem permissions.
I think that ship has sailed - that’s the original argument against receive-only: Set appropriate permissions to prevent writing locally. Nevertheless we have this folder mode now, so it should work sensibly.
And to me receive-only is not about not sending files to others, but not sending locally modified files to others. And as we would send changes by other devices on, we should also propagate conflicts originating on other devices.
I guess this depends on which side wins the conflict resolution… If the send-receive side (“C”) wins, there is no conflict copy there and what you describe happens. If C loses, it will create a conflict copy and everything works as expected. Seems like maybe receive only folders shouldn’t ever do conflict resolution and just pass along the latest (in wall clock time) version seen? Then either of the normal-mode sides will always have to do the resolution.