I'm wondering about "Receive Only" folders

Feature
21

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:

  1. Create a special user account for syncthing
  2. 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).
  3. 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?

22

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
23

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.

24

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
25

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 :slight_smile:

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.

26

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.

27

If you want a mandate, then syncthing is the wrong tool, as it’s distributed collaborative, not distributed mandated.

28

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?

29

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
30

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.

31

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!

32

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?

33

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.

34

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…

35

In general for most of your posts in this thread: TLDR. AudriusButkevicius has been responding repeatedly to the same questions for years now. If you can setup a different account to run Syncthing under, you can remove write access for all other users to the folders you want to be receive only. That way Syncthing is the only thing making changes in that folder… Even if Syncthing had receive only folders this would probably be a better option for most people.

No… You would give the new user access to read / write in existing send receive folders. The only thing that would have different permissions would be the receive only folders.

36

Your scenario is not the only possible one. Consider a small design studio of five people who use Syncthing to keep their work in sync between their laptops. They’re not always all at the office at the same time, etc.

One of them thinks this checkbox sounds good but doesn’t really understand what it does. For the next couple of weeks, whenever this person is in the office, other people suffer random deletions and reverts of their work. In the end they realize Syncthing is what’s been destroying their work, uninstall that shit and curse my name forever.

2 Likes
37

Yes, this is a possible scenario, and to prevent this - the option to autopress “Override changes” should be available only by manual editing of settings file, not chechbox in GUI.

38

Calmh, My understanding matches how you responded to ildary. Shouldn’t happen automatically or users will be surprised (breaking one of the tenants the authors name as a design principle).

Ildary, consider if a file appears in the peer of a Send-Only node from some action outside of Syncthing. You can’t push the file to the Send-Only node because it’s send only. You can’t just automatically do the Send-Only operation and delete the file that appeared in the peer because the user almost certainly did not put it there intending Syncthing to destroy all copies (they would have used the trashbin for that function). Because of this is why the override button exists for Send-Only.

Kluppy, TLDR only because some developers are repeatedly saying the same thing over and over. You blame the repetitive chorus on the users. Perhaps users are only responding to some of the developer’s repeated demand to defend the user request. Developers are important and donate tremendous effort. Nobody would have any Syncthing without them. However, at some point, Developers need Users. I wish the growing chorus of users was heard without the same flippant “do it with file permissions” come back. In the last 3 days I’ve posted specific desires that cannot be answered with file permissions and that didn’t stem the “do it with file permissions” quip at all.

More pointedly users should not be crucified for simply having a request. Help them understand an alternative way? Yes. However, developers need to put equal weight to understand why that’s an insufficient answer for some users. I have answered Audrius’ requirement that a simple desire be defended over and over. Instead, in this post, I’ll address the deep architectural and philosophical reason that Syncthing must include SR, SO, and RO folder types to be complete.

Calmh, You spoke about “more override buttons” and I think you meant it in a negative way. Why negative? My point is not the button count, but rather that the third folder type seamlessly and intellectually perfectly dovetails with how the Send-Only folder type already behaves. The symmetry is a perfect match.

Opposite of what others want? I haven’t found any conflict unless someone is brand-new and misses a point about how Syncthing operates. At this conceptual level, it has nothing to do with programming or override buttons (those are all at the implementation layer and can be debated). There is no debate about the architectural issues and completeness of 3 folder types. Here’s what I mean…

The issue and request to the designers is much deeper. When you have communicators or data sources anywhere in the world in any architecture, the fundamental design character is that communicators can 1) send, 2) receive, or 3) both. Three things. No more. No less. I and others are asking that Syncthing is a “complete communicator” - capable of doing the natural range of being a communicator. It’s not clear why many of the Syncthing developers recoil at the suggestion of the full 3-set of communication capabilities. Although the repulse is heard, no developer has said why they hate the users so much for asking for it. If developers love tool chains and want to paste together OS functionality of file permissions for their needs, great and go for it! However, you’re asking your common smart phone user to implement file permissions? Please…

Not implementing the complete triad (SR, SO, and RO) would be like a wrench that only tightens bolts, but not loosen bolts. That would be unnatural since the work of a wrench is inherently (universally) both. Likewise, the scope of a communicator (Syncthing included) is to send, receive, or both. This character of the universe is fixed regardless of your or my opinion.

In my post yesterday, I proposed 3 bullets about how the 3 universal comm methods should be implemented with folder types and how they should each behave and interact in Syncthing. You have already implemented the SO and SR folder types. All I’m asking is you complete the logical triad to include the RO folder type. There is nothing cosmic or incendiary about completing the triad. In fact, when written out in 3 bullet points, it rather elegantly scopes the issue because there is no logical extension to 4 folder types, so when complete, you’ll know the work is complete.

39

For newcomers to the thread, realize there appears to be two similar threads. Check them both out for full understanding:

Also, here is a “proposal on the table” of how to implement the proposal. If users coalesce around this description, it would be easier for developers to make the change.

40

@calmh I’m a little bit late to reply, but would that person, who ticks the checkbox “overwite automaticly” only activate it on his own laptop? So he would only get all his own files automaticly overwritten, but not the files on all the other laptops in the studio.