Well, life is hard, and then we all die in the end 
Disk permissions can prevent changes from happening. Changes that don’t happen don’t sync to other devices. Hence, receive only.
These can be ignored, or not created to begin with if the user browsing the files (thus creating .DS_Store or thumbnail caches) doesn’t have write access to the files / directories - i.e., see above.
I believe this discussion is going in circles, we heard all these arguments many times before. In the end it’s clear that there is a demand for this, but it is also both difficult to define what the exact behaviour should be and to implement (two people already tried without finishing). So this falls in the “nobody bothered to do the work yet” category.
1 Like
The problem seems to be that ‘receive only’ means different things to different people… hence the confusion. I still maintain that using disk permissions would be pretty useless for most cases, except a copy-once, frozen-forever scenario. If, for example, someone wants a receive-only where they may want to delete some files now and then without the deletions being propagated back to the others, then you can’t fix that with disk permissions.
Correct. And those files would have been immediately resurrected / re-downloaded by the receive-only proposals that have been circulating so far, so the agreement on what receive only means is definitely less than 100%.
I think someone who cares about this should start by writing down exactly how they expect this folder type to behave, and which use cases it solves. That includes mentioning what happens in all the corner cases we can think of (like files being deleted, changed or added). Once there is a logically consistent view of how it should behave it’s easier to implement.
Some things are unacceptable to begin with - for example outright deleting a file that a user inadvertently moved into a syncthing managed receive only folder. Other things just need to be considered - should we somehow announce to the outside world that we are out of sync when that is the case? How, if we are not sending index data? Things like that we can assist with once the desired behavior is known though.
3 Likes
I’d like something like receive only too, but as I read a part of all the discussion about it, indeed lots of various expectation are behind these same words. Maybe formuling in first step a few scenarii to be sure everybody expects the same various option behaviour would help to afterwards create what is needed.
So here is my point of view : I see a 3 level abilities : master, collaboratives, slaves. A master is read only, nothing affects it because none should update him. It can be set locally as a deaf device. Collaboratives are the usual level devices : one change on anyone propagates changes to the others. Slaves receive only and no other change from local action should be propagated. They are muted devices. Status modification should be set from addition of authorization from both local and other devices. A device pretending to be a master should be alone in the cluster of this level. The case of at least 2 masters at same time should lock the propagation of any changes from each of them. Other devices can’t promote themself as master as long as a master is present. But even in this case, a master never listen to the others so no change can occur from the cluster back to him. A slave is set as slave by a master or a colaborative, or by itself. As long as one of these condition is set, the device remains a slave. So a slave cannot promote itself (but can unset himself as slave) without akcnowledgement of the others, and can’t change/mess up because not allowed. It could be considered as muted, or other collaboratives may be deaf to its’ changes.
This should solve all the part of adding files. Concerning deleting, from master and slave point of view, no difficulties : one serves, the other obeys and follows, like now when files are changed. The collaboratives point of view isn’t obvious. If changes occurs between them, how should they handle the will of the master ? I propose, as long as they follow at least the rule of the master, they may add, modify or delete other files and propagate between each other collaboratives. But what about slaves ? Should they follow the master only / or the master and the collaboratives ? Well, the 2 cases could be handled by the 2 level authorization : A slave set as slave by the master follows the master only; if set by at least a collaborative it follows the collaboratives considered as sender only, and if set by itselfs, it follows the master only. So I think all cases should be handled. Now, how to display the stats and status of the cluster… I didn’t think at it yet.
Waiting to see your opinions 
In a distributed system where you might not even see part of the mesh ensuring enforcement of only one master is no possible. Also, if you do have two masters, given let’s say you have a malicious actor, you suspend syncing essentially giving in to DoS… What if you see only one master but someone else at a different part of the network see’s two? What if the master is offline, so no sync happens between other online peers? What if you saw two masters but one of them went offline etc? What if there is a network partition between the two clusters that each have their own master?
It’s cool and all, but this needs more than 3 sentences produced while drinking coffee to make it even remotely viable.
Everyone ever screaming about receive only has never been able to explain why does this not solve the problem:
- Create a special user account for syncthing
- Run syncthing as that account with ignore permissioms umask that only allows this user write access and others are only allowed read access (and run syncthing only, nothing else under that user).
- Use the computer with your normal user who then CANNOT create, modify, delete files or folders in the syncthing directory due to permissions.
How is this different from the nuclear “receive only delete/undo everything else” folder?
Audrius,
Your comment “Use disk permissions” repeats what has been said, but doesn’t add any content to the discussion. Do you understand that that solution is not the answer for some people? For example, disk permissions do not help because the disk permissions would simply name myself, and I’m the one I don’t want to accidentally do something. If you are talking about creating a new user or group with unique syncthing rights, then that is a requirement for me to change my data in order for syncthing to work. At that point it is not a passive tool, it is an invasive mandate on what my data must look like.
1 Like
Jakob,
Regarding, “some things being unacceptable” like deleting a file accidentally landing in the receive-only folder…
Yes, I understand that simply deleting the file would NOT be a good solution - the user would be really angry that it just vanished. However, you have already solved that in the reverse case (send only) by including the red override GUI button. Do the same. Syncthing would notice the discrepancy and just like “Override” forces a sync outward and ~does~ potentially delete files, you can do the same in reverse. The “Override” button on a receive only node would mean to accept all changes necessary to match OTHER nodes, including deleting every single file if necessary. This threat is mitigated by not DOing the changes until the user poked the “override and accept all changes including massive deletes” button.
Jacob,
No outside announcement is required. The “receive only” character belongs only to that one node and other nodes should not care that the receive only node is offering no changes.
“Out of sync” in this case is defined only on the local receive only node, so a GUI “override” button would pop up on THAT node and if the user presses the button, then any differences are resolved in favor of the other remote nodes, to include file add, deletes, or mods.
1 Like
Sorry but time to write the answer didn’t let me time to read previous message, so here is my answer to @AudriusButkevicius Audrius :
Everyone ever screaming about receive only has never been able to explain why does this not solve the problem: Create a special user account for syncthing Run syncthing as that account with ignore permissioms umask that only allows this user write access and others are only allowed read access (and run syncthing only, nothing else under that user). Use the computer with your normal user who then CANNOT create, modify, delete files or folders in the syncthing directory due to permissions. How is this different from the nuclear “receive only delete/undo everything else” folder?
In general, I don’t know because I’m only “one” user, and my advice doesn’t represent all the various users. But in my particular case, I run only one master locally and the sync net works with other distant users in other countries, so I can not change anything but the rules available in syncthing.
It’s cool and all, but this needs more than 3 sentences produced while drinking coffee to make it even remotely viable.
There is absolutly no doubt about that. That’s why the problem remains for a while and as Jakob Borg said, that’s why it needs to be clarified in expectation by userS (not me alone) to tell what seems needed and how it should behave. I write “seems” because if we can find an allready existing solution, everybody would be happy to use it ! Just let us know how to then
In a distributed system where you might not even see part of the mesh ensuring enforcement of only one master is no possible. Also, if you do have two masters, given let’s say you have a malicious actor, you suspend syncing essentially giving in to DoS… What if you see only one master but someone else at a different part of the network see’s two? What if the master is offline, so no sync happens between other online peers? What if you saw two masters but one of them went offline etc? What if there is a network partition between the two clusters that each have their own master?
I would consider this like a DHCP server. Sometime there is none, sometimes there are 2 official, sometimes there are rogue… To consider the cases you mention : 2 master at same time (rogue or not): no update from them and because they are master, no update ever to them. Allways obey at present master if he is alone. Noneless, a fake master couldn’t have more power than a regular device has now. So the problem with a rogue master is less important than a rogue regular device like it is now. No master means actual behaviour (except for slaves). I don’t understand your cluster and partition problem : there is just like now a cluster and you are in or out. But there is only one master.
Audrius,
It appears that this leaves me (as the normal user) unable to modify my own files in the Syncthing directory. That is unacceptable. I am not trying to silence or argue with you; I am trying to answer your question why file permissions do not solve the problem.
I (me, the normal work computer user) want to be able to add/delete/mod all files as I would if Syncthing didn’t exist. Plus, this would require the permissions on my data (files) to be changed. I don’t want Syncthing to force me to change my data - I simply want Syncthing to sync my data.
However, your suggestion is good for some special use cases where the added requirements and restrictions are acceptable.
If you want a mandate, then syncthing is the wrong tool, as it’s distributed collaborative, not distributed mandated.
Isn’t receive only all about enforcing remote state locally? In which case you wouldn’t be able to modify them anyway?
If you want syncthing to sync your data, just let it do it with send & receive, what are we even talking about here?
Audrius,
Your responses are often short and curt. You said something about me “…wanting a mandate…” but I don’t understand what you’re arguing against, much less what you disagree with.
If you want people to understand you (maybe even agree with you sometimes), you simply have to explain more rather than chop conversation with some iconic statement you believe but communicates nothing to the other person.
I apologize, but I simply cannot follow your points when you flip out short snappy responses.
1 Like
Audrius,
I am simply asking for reciprocity and similarity with how Syncthing already does the Send-Only folder. I mean that I can add files into a Send/Receive peer and an associated Send-Only folder with display a red Override button. At that point, I can override and force things back they way they were.
I really really really do understand that you don’t want the functionality I am asking for. Although you repeatedly put me and others on the defense (I mean that literally when you type: “You must defend why you want to do it your way”), wanting something different is not a reason to lambast others.
Hypothetically, perhaps I want my child to be able to make all sorts of changes and then at the end of the day I can simply go to the Send-Only peer, press the Override GUI button, and have all the kids’ changes undone. Why do you demean this desire so much? Be free to disagree, but why do you lambast others that want this?
How I am asking receive-only to be implemented is modeled after how send-only works. It’s a very small conceptual change if you are willing to just try it for a moment. I want to allow changes in a Receive only directory - no errors, no file permission refusals, no nothing. Maybe for security reasons, I want to allow someone to make changes thinking they have changed the directory. Maybe I want to LET them make changes to the receive-only directory and I want to allow those changes to persist until my time of choosing. But Syncthing should offer me an override button, so at some time of my choosing I can use the GUI override button and make the receive-only site re-match everything the Send-Receive peer has.
I will separately post an entire “what should happen” design, per the request Jakob made, in direct reply to his post.
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!
I would like to see “Receive only” folders too, but I see that the developers are against this. What if instead of “Receive only” folders, Syncthing will have an option: Press “Override changes” automatically?
Your proposal calls for more override buttons. Before looking at any of the technical details it strikes me that this is the opposite of what everyone else so far has proposed. I don’t think it would be a popular implementation.
This has been proposed before. It means that a single device inadvertently configured like this will be deleting files and undoing changes all over the cluster without any visible indication that this is happening or where it’s coming from. It is dangerous and confusing.
Excuse me, but this is not dangerous - this is what user want Syncthing to do - maintain equal copies between devices.
It could be dangerous - if user syncronize folder with another unwarned user, but it is impossible - before start syncronizing you have to pair device etc…