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.
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.
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”.
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.
We have 4 types of folders (as I see it, not necessarily as syncthing sees it) at ours.
Pauline’s folders
David’s folders
Collaborative folders
Housekeeping folders (just to move stuff around).
The proposal is only relevant to the first two types.
Relevant devices are a laptop each and a local and remote server.
The remote server is only connected to the local server (via st) as upload speed is limited.
The remote server keeps just one previous version, the local one keeps more. Versioning on the local server is a free extra, a nice to have.
Neither of us has a local copy of the other’s folders. To see them, we need to ssh to one of the servers.
So, for these folders, st is used for protection against media failure or the house burning down. It also gives some protection against finger trouble with versioning.
I was hoping for the complete elimination of persistent sync conflicts on the servers for owned folders, but on further reflection, I’m not sure that this will happen. I’d appreciate thoughts on this.
This proposal sounds great and seems like it will satisfy my usecase. I use ST primarily to sync my photo library from my phone to my other machines. The authoritative source is the folder on my phone. Occasionally I delete older photos on machines other than my backup server, and I don’t want those deletes propogated. The only thing missing here is the ability to choose to “Partially Revert”, so I could choose to restore some amount of photo history but not the entire multi-gb folder.
What would be the behavior according to the current proposal in this scenario:
node A (send-receive)
node B (send-receive)
node C (receive-only, always-on)
Node A & C are online, B is offline.
A modifies files, C accepts them and both are in sync.
Now, A goes off-line, later B comes up online. Right now B has the “old files” while C is up to date with modifications it got from A. Now C is receive-only.
What would happen? Will the receive-only C (since it knows from A that it’s status is the “correct one” in the cluster) push the updates to B? Or only A would be able to directly update B?
Even if C is receive only, it doesn’t introduce any modification on its own, it’s just acting to deploy (or help to deploy) the situation received from A and propagating it.
IMHO…
Being receive only is a question of files originary source, not meaning to stay out of the cluster when it’s time to help propagation.
Yes, that. Sending and receiving here refers to modifications, not data as such. It’s allowed to send data, it’s just not allowed to pick up any local modifications. So it’ll send everything necessary to bring B up to date.
Imagine three peers are in the sync group, each with a different
character. All three types don’t need to be present or duplicates of types could 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.
This is not what I propose, and I don’t want to change my proposal to accommodate. There are technical reasons (the receive-only device would need to send its changes with some new magic flag set to indicate that they are that kind of change, so the send-receive device can see it and trigger the override), and user experience reasons (I don’t think override makes sense as an action on a send-receive device, and the receive-only state is a local decision on that device that shouldn’t “infect” the rest of the cluster).
Showing the override button on the send-only device might make sense, as noted above.
Showing the button on a send-only device is already done if another node first changes. So, yes, it makes sense because that’s what already happens with the current release.
I didn’t propose anything would show on the SR node in the “change RO” case, so I’m not sure why you spoke of a button on the SR node (if there even is a SR node present), or how the “infect” comment connects.
The question is if RO changes, should a button appear also on RO. If RO changes from the rest of the world, it is a local display based on a locally generated condition.