A ---- B
\ /
\ /
C
“A” should be receive only. With the advanced suggestion we could do it on A itself (“do not propagate changes”) which is about equivalent to my topmost proposal. Or it could be done on B/C but then it needs to be done identically on both to make sense. Maybe this is fine and the usual way to set it up would be to set the flags on A, but the filters could be implemented on B & C as well for extra safety or something.
I understand you can’t mitigate that, hence why it would be an advanced option other than the dropdowns potentially with a good chapter of docs covering pitfalls.
As the current model does not allow any control at “cluster level” and the ensuing pitfalls, I kind of like the current choices where you can only set restrictions on the local folder/behaviour. It makes it pretty clear that you cannot control what happens outside of the device/how other devices behave, only what your device does about what happens outside.
For a question of locating the place where this decision is set, and following my response #2 in this thread, I would then prefer to set locally that “I don’t want to be locally disturbed by any changes occuring on that only particular other device” if I cannot set it remotely to be receive only.
It’s not a way arround to keep saying it, but a way to conceptualize the relation between these devices.
Thanks 
For me that behaviour would make sense.
Note that before reading that topic, I had another idea how to solve this kind of scenario: New Folder type: Receive Only
My idea would require more configuration (multiple “send-only” devs instead of one “receive-only” dev). However, to protect nodes of the cluster, it is more intuitive to “setup shields” on the nodes to be protected instead on the “intruder”.
Hi @Martchus; would you please read this and give a feed back. Thanks. https://forum.syncthing.net/t/im-wondering-about-receive-only-folders/9229/20?u=brunod
@brunod Sorry, but that sounds way more complicated than necessary. I like my approach more because it solves the “receive-only” use case without even introducing a new folder type. I’ve also read @AudriusButkevicius answer and agree.
Thanks for your answer. No sorry, we all just try to progress
But, at present time, what happens when there are 2 “send only” devices/folders with different contents at the same time among other “send receive” devices/folders ?
If we add a status “receive only” as requested, how should it behave if there is, among usual “send-receivers”, a “send only” device/folder ?
These are the case I wanted to handle.
Thanks, BD
The problem with this is that Syncthing works as a cluster… Unless every device in the cluster is set the same way the changes will propose through the cluster. Example, 3 devices A, B and C. A is set to ignore B as you suggested but C isn’t. Something Changes on B and it announces the changes. A ignores B. C accepts the changes and syncronises. Then C updates it’s state with A. A sees C has a newer state and syncronises the changes.
This does not scale well at all, I only manage 6 devices but over all of the folders there would be too many places I could make a mistake in one of the configuration options.
I know, that’s why I wanted in first place to set it remotely on the ignored device; but that’s against syncthing policy. So I don’t know where else it could be set… Because if it depends of the ignored device itself, it’s like closing your door with the key on the outside.
I like the proposed approach.
For me “receive only” means “accept stuff, but don’t alter the cluster with local changes, while being data-safe first and never auto-wipe stuff”. And the described behavior is what would I expect.
Typical use-case: backup/accumulator/replication node, in conjunction with some versioning scheme.
Only minor notice: I think the “override/revert” buttons’ naming will confuse some users (“is remote devices state will be overridden or local?” “revert which changes, local or remote?”). I don’t have a clear solution, but it should emphasize in a non-ambiguous way what is going to be deleted/overwritten.
This sounds good, but I wish I didn’t have to be an industrious user in order to get it to do what I want, which is always “Revert” on the Receive-Only side and/or always “Override” on the Send-Only side as soon as the Recieve-Only side is out of sync. I would like to use this as a backup solution that I don’t have to think about. The current mode of going in once a month and finding “Override” buttons to press is annoying, and finding a “Revert” button instead doesn’t seem any better.
That may make sense as a switch behind an “Advanced” setting, so people who really want this kind of “edgy automation” can get it without being skilled at API. While keeping the “normal” behavior to prioritize data safety.
My personal use case would be the following:
There is a folder on computer A that contains various interesting things. Computer A is the “owner” of the folder and is the only one that should ever be able to change anything in the folder.
Computers B, C and D would like to have access to the information in this folder. They can’t necessarily reach A to mount its file systems. Computer A may not even be turned on when computer B wants to see its files. Therefore I use syncthing to ensure there is always a local copy of the folder in question.
The people using computers B, C and D should not attempt to change anything in their local copies of the folder, but mistakes can always happen.
With the current version of syncthing, I set the folder on computer A to “send only”. This protects it from receiving any changes from B, C or D. However, if (for example) B mistakenly makes some changes, those changes will propagate to C and D and will remain propagated until A overrides the changes.
The current proposal would provide one more level of protection: Since I’m in control of syncthing on B, C and D, I could set the folder to receive-only on those computers. Then, if the user on B would make changes to the folder by mistake, these changes would not propagate to C or D, which would protect those users.
There are at least two other variations that would make some sense in my particular case:
An “automated revert” setting that could be activated on computers B/C/D. This would cover the case where A is truly the “master” and where the policy is that changes on B/C/D will only be temporary because the folder is truly just cached “pseudo-read-only” copy of the folder on A. But this is far less important to me than protecting folder copies on other computers.
A centralized “I’ll always override” setting on the master folder (to avoid the need to make external API calls to handle this). This would be similar to “automated revert” but you would only have to set it in one place which would simplify configuration in my case. But I understand that this in some sense implies a different “authority model” where everything would be less peer-to-peer and folders have true owners.
In summary, I think the current proposal would be at least be a significant improvement for my use case.
I’m in the same case that could be summarized like one centralized data center and various distant readers. Beware that the place where you set up this protection (receive only) has to be, according actual syncthing policy, only on a local device. So it can not be remotely set nor you can’t be sure the distant user won’t revert it.
Yes, that is true. I should have clarified that in my specific case I have cooperative users that would only change things by mistake, but as they are not necessarily technically inclined, I would like to protect the group against accidental changes to the greatest extent possible. These users generally don’t use the Syncthing interface at all simply know there’s a folder with certain files they are interested in.
I would just like to chime in and say that I am very much in favour of this.
This would serve me very well in many ways, but mainly:
A lot of my important data is sent to a couple of servers that are not at my home. These servers run ZFS pools to mitigate the risk of data corruption - as do the rest of the servers/workstations in the cluster. If data corruption were to occur on one of these ‘final line of defence’ boxes before a scrub fixes it or I restore from a backup, receive only mode would stop it being pushed back to the rest of the cluster, but I could still have the rest of the cluster syncing.
Another use is that I write my some of my work and family data to one of my servers after temporarily enabling write access to it, the data of which is then pushed back to my workstations. After this, the server write access is disabled. This is to mitigate the risk of ransomware etc, as the server is send only for the particular folders in question. If I had receive only mode on the workstations, I could change this particular server to send/receive with one of the other servers as yet another layer of protection.
This feature is very much of interest to me.
My story about problem with “Send only” folder:
I share a folder between two computers: First PC is “Send only” and on second computer this folder is part of Dropbox (for online backup, because Dropbox cannot run on first PC - old OS). When second PC is rebooted - Dropbox creating (and deleting) files in every subfolder: Desktop.ini and .Dropbox. And after this, date/time of my folder (on second PC) is changing and first PC demanding to press “Override changes”.
@ildary: That can be easily solved already - just add the unnecessary/problematic temporary files/folders to the ignore list (https://docs.syncthing.net/users/ignoring.html).
Excuse me, the problem not in files (they was created and deleted 2 seconds later), but in folders - they date/time was changed and ST stopped syncronizing.