DO NOT CLICK "override changes"

A use case from real life.

I setup my 2 tablets 1 phone and PC to do a one way sync. Or so I thought… it turns out “send only” is not as the name suggest. No it creates differences (naturally) as different files are saved and not synced to the other devices. but then a “override changes” button appear. I thought "it will override the error (changes) log or GUI. I did not expect it to remove ALL the files on the other devices (worst, I thought, it would only mess up the device I pushed the button on), I did after all set it up as one-way. So if a developer reads this please change the wording or at even better make en option for true one-way.

And no, I cannot do an undelete as the PC has a SSD with TRIM enabled. Nor does it seem that android has the option for non-rooted devices.

Maybe reading the documentation helps



I’d suggest a message box popping up on button press with a sentence explaining “that it does force other devices to have the local folder’s state” and that this also means deletions are enforced with a red yes and a grey no button. The user would still have to read the docs and understand Syncthing but “clicking by accident” would be prevented.

  1. I tend to agree that a confirmation is appropriate here. The button is already red (danger) and it will annoy users that took the time to actually read what the folder types mean (either in the folder edit dialog or the docs @Andy linked above), but these (override and revert) are potentially destructive operations, so that annoyance seems justifiable.

  2. While I still think the folder type names and descriptions are appropriate, they clearly couldn’t convey their meaning to you (@Teddy). Thus I am interested whether you would have selected “Yes” or “No” if a popup with the following text would have appeared after pressing “Override”:

This is dangerous operation, which will change and/or delete data - make sure you understand the consequences before going ahead.

You are about to override all remote devices with the current content of your local folder. For example a new file added on a remote will be deleted on all remotes, or a changed file will be overwritten with the file present locally everywhere. For more info on folder types, see the docs: Folder Types.

Are you certain that you wish to continue and override changes?

Obviously that question is flawed as you now know more than you did before, I still would be interested in your answer.


I also vote for a big red confirmation for both “Override Changes” (Send Only) and “Revert Local Changes” (Receive Only).

In addition, I know that this has been proposed many times before, but I personally would strongly suggest enforcing sensible default versioning (e.g. a 7d trash can). This would help prevent this kind of disasters for new users, and experienced users will be able to easily disable it anyway (especially once the new folder defaults configuration gets implemented, possibly soon).

1 Like

I agree on the confirmation (though it needs to be much shorter and to the point, I think, maybe something like “Warning: the folder contents on OTHER devices will be overwritten to become identical with THIS device. Files not present here will be deleted on other devices.”?). Let’s await configurable defaults before discussing how to change the defaults going forward…


When I get a ‘revert changes’ on the Send Only side, i’m never sure if it’s deleting the actual files, or the references to the files in the database. In theory, on SO, it shouldn’t even come up as that’s the master set of files, but for some reason it occasionally appears

You seem to be misunderstanding one of the base principles here, that is: Syncthing treats all the nodes as equal. There are no “master” nodes that tell others what to do, and there are no “slave” nodes that do what they are told. Every node governs itself.

A random node somewhere in the swarm may not even be aware that there is an SO node. The only node that is guaranteed to know about SO node’s existence is the SO node itself. The other nodes may not even know they have changes that SO node does not accept.

Revert changes is basically a command for SO node to tell everyone else: “Here’s the current state of the folder, this is how it should look like, this is the latest and greatest!” Then the other nodes be like: “Oh, this new file is not in the latest-and-greatest state of the folder, so we should delete it”, “Look, this file’s version is not what is in latest-and-greatest, we need to replace it (thus removing last week’s work”, etc. So of course revert changes appears on the SO node, not the other nodes — only the SO node knows that it’s the SO node.

Except the wording differs: It’s “Override Changes” for send-only, and “Revert Local Changes” for receive-only.

That’s right, my bad. I rarely use the English interface, hence the confusion.

I would have pressed yes, as I still think the “override” should be replaced with “force delete”. Or something similar, unless explained it will delete files on all other devices as you suggested in your post. The wording @calmh is using is short and to the point. Maybe a combination would be a the way? the short version and a “read more” with your more detailed explanation.

This is in my mind not a bad idea, when using this function. Good thought!

This is a contradiction in itself. in “send only” mode they will be unequal the first time a file is deleted in another node.


Maybe the button should change name, and come with a warning. I know I the one who made an error. Yet you can not document your way out of human stupidity. My view on a CAPA is:

  • Corrective here and now: none since the data is lost and cannot be recovered.
  • Corrective in the future: A 7 days grace period as tomasz86 suggest.
  • Preventive: a 2 stage dialog box, with a short wording like calmh wrote, but with a “read more” / “detailed explanation” link with a more thorough explanation like imsodin wrote.

P.S Why new users can only mention 2 users in a post? a counter productive limitation.


No, that just means their state is no longer identical. They’re still making decisions about how to manage their own state independently and based on the information available to them. As you noted in the original post, the send only setting didn’t do what you expected - that is the root issue here.

Out of curiosity, what do you mean by “true one-way”?

I mean a way where it is set, and under NO circumstances can be affect other nodes. Nor can it under NO circumstances enforce a delete command. Therefore in logic, true one-way.

Well, in that case you should presumably just not have any kind of syncing. You obviously expect some effect on the other nodes.

I’m asking you to explain what you mean by that, so that’s not helpful. To be a little more specific, then, I’ll ask these two questions:

  1. How do you expect a “true one-way” to work if it should not lead to differences in state between the nodes?
  2. How would you expect a “true one-way” system to reconcile state differences between nodes when asked to?

What I’m fundamentally trying to ask is what you expected to happen. That is not clear to me.

5 posts were split to a new topic: Automatic send-only folders when accepting shared folders