A proposal for a receive-only folder type

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.

Guys, let’s try and keep this thread on subject of discussing the proposal.

4 Likes

A post was split to a new topic: How does send-only work

I’m strongly in favour of the proposal.

We have 4 types of folders (as I see it, not necessarily as syncthing sees it) at ours.

  1. Pauline’s folders

  2. David’s folders

  3. Collaborative folders

  4. 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.

1 Like

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.

1 Like

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.

4 Likes

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.

1 Like

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.

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.

This is addressed in the first 3 bullet points in the opening post. In short: a local “Revert” button will appear in RO, pressing it will remove RO’s changes and override them with cluster’s “correct” state.

My bad, I misunderstood you. Yes, the receive only device will get a button, but I propose “revert” instead of “override”.

1 Like

I have some questions concerning this revert function, just like for the override button : How does/will it work ? When it says there is something to override, I have to push a lot of time to achieve the sync back to correct state. But I can not list (or I didn’t find) the files that will be overriden. So I cannot be sure of what files/modifications will be overriden. At present time, I don’t really matter because it’s my master that rules the cluster, so I’m sure he is right and he has to impose it’s state. But I think I miss something and if this same behaviour is transposed to RO, I’d like to be sure (for me and all users). Thanks. (I didn’t split this question from this thread because it’s RO related, but if needed to split for better readability, I’ll understand :slight_smile: )

The list of out-of-sync files is there on the send only side, clickable somewhere among the folder details. Those are the changes that get overridden when you press override.

I expect we could use a similar mechanism to show the files to be reverted on the receive only side.

3 Likes

This would be an awesome feature. Please proceed!

Ok, this proposal nails it down very precice. Thank you @calmh!

That seems intuitive to me, but on the other hand…

…I’d like to not have a (reddish nagging) button on the Send-Only folder for overwriting/revert changes on a Receive-Only folder.

Changes on the Send-Only folder should always (and silently) be overwritten or deleted on the Receive-Only folder. I’d like to have the Receive-Only folder to never send/overwrite/anounce any files/folders to other devices. Which is most likely this:

This is mainly my point of view for this topic and I don’t add any other “what I want is…”, because I made it here already here and here, and ppl. here also wrote, what I wanted to say.

Thanks again @calmh for your constructively summary of all our thoughts and words.