Explanation about "Receive only" synchronization and the words "Local Additions"

I have read some discussions on the subject, but I did not understand well: partly my difficulty in understanding, partly an imperfect Google translation.

I try to re-propose the question in the most schematic way possible. Unfortunately I am forced to dwell on it. I hope in the patience of a kind person who will read me to the end and who will answer me in the simplest and most schematic way:

  1. my intention is to save a 1: 1 (identical) copy of an android folder on the NAS via Syncthing.

  2. Consequently I have chosen between settings the option “Type of folder”> “Receive only” because on the NAS the files coming from the android folder must NOT be modified. Unlike in the android device, in all the folders affected by the Syncthing synchronization I have set the option “Send only”! (I also double checked).

  3. After a few days, opening the Syncthyng configuration on the NAS, I find most of the folders with the words: “Synchronized” and a couple of folders with the words: “Local Additions” as if I had modified some file in the NAS folder that says “Local Additions”

  4. assuming just for a moment that I actually changed that folder on the NAS, even if I don’t remember doing it, AND IT MUST NOT BE DONE BECAUSE IT IS A BACKUP (!) the wording is correct, it should be possible - manually - to resynchronize the folder of the NAS with the folder of the android device, making the folder of the NAS identical to that of the android device - WITHOUT MODIFYING THE CONTENTS OF THE FOLDER IN ANY WAY IN THE ANDROID DEVICE !!!

  5. Now, the red button “Reset local changes” as far as it indicates, it seems to do what is indicated in point 4: it should make the folder of the NAS identical to that of the android device - WITHOUT MODIFYING THE CONTENTS OF THE FOLDER IN THE ANDROID DEVICE IN ANY WAY "

  6. Instead, in an attempt I made by pressing the red “Restore local changes” button, the contents of the folder on the android device have changed profoundly. Luckily I had an additional backup copy.

Then, how to interpret the “Reset local changes” button? And above all, if for any reason, the copy of the folder saved by Syncthyng on the NAS becomes different than the folder saved on the android device, how should i do to recreate an identical and updated copy?

Hi @kRel ,

To begin with, please read Folder Types — Syncthing documentation . It contains a better description of this than I could possibly give.

Almost correct. The button in the Receive Only end, NAS, is named “Revert Local Changes”.

There is no such button. But in your Send Only device, Android, there is a button “Override Changes” which causes exactly this behavior. I think you pressed that one by mistake.

2 Likes

I don’t think this is correct, is it? Pressing the “override changes” button on a Send Only side will override any local changes in Receive Only folders on remote devices. It will not push any changes to the Send Only folder itself.

I think there is an issue on GitHub about having an option to one-time “accept” changes in Send Only folders, but it hasn’t been implemented yet. At the moment, if you want to accept changes in such folders, I believe the only way would be to change its type (either to Send and Receive or Receive Only).

Restoring local changes in a Receive Only folder should only make the folder stay 100% in sync with other devices, deleting anything changed locally in the process. It should definitely not have any effect on the folder on other devices.

Could you please post screenshots from both sides showing your configuration in detail?

1 Like

Good morning everyone again. To limit any translation errors (unfortunately I don’t know much English … damn!) I will still be schematic and unfortunately again with a long discussion. I apologize for this.

Not having been satisfied with @martinleben’s explanation, whom I thank anyway, I did two tests creating in the android smartphone a new “TEST” folder with files and folders inside. After completing the first test, after deleting - source side and target side all objects and the “TEST” folder, I repeated a second test identical to the first creating in the android smartphone a new TEST2 folder with files and folders inside.

In both tests the origin (android smartphone) Syncthing was set to “SEND ONLY”, while the destination (the NAS) Syncthing was set with “RECEIVE ONLY”. (I quote verbatim the wording in Italian present in both devices)

What did I find?

both in case of additions - and in case of deletion of objects from the sender device, the changes are mirrored on the recipient device.

THIS TO SAY THAT: if the “Send only” setting has been activated on the sending device, and if the “Receive only” setting has been activated on the receiving device,

IF in the sending device (smartphone) an object is deleted, the deletion is repeated also on the target device (NAS).

SO IT IS “MIRROR SYNCHRONIZATION”! - NOT “ONE-WAY SYNCHRONIZATION” (as the phrase “Send only” might suggest) - CONSEQUENTLY THE PHRASE “SEND ONLY” IT’S MISLEADING !

I don’t know if this is wanted by the makers of Syncthing, or is it a mistake in the translation. But said so, IMHO it’s wrong!

You seem to be describing a file being deleted on the send-only side, and this change being sent to the receive-only side, where it is received and acted upon. This is as intended. Changes propagate from sender to receiver.

4 Likes

If I were to explain this in simple words, it would be as follows:

If you do changes in a Send Only folder, they will be synchronised with other devices. If you do changes in a Receive Only folder, they will not be synchronised with other devices.

The original problem sounded like the opposite though, as if you had deleted a file in the Receive Only folder, and then that deletion was synchronised with the Send Only folder.

1 Like

Exactly ! It seems trivial, but it is not!

It is one thing to say “Synchronization with send only” (Send only) very different is to say “Mirror Synchronization”!

In a sync with send only if objects are deleted in the destination, deletion does NOT propagate to the source!

Objects deleted in the destination - by sending only - remain in the source!

Hi tomasz86 :slight_smile:

As I said, I have problems with English. I tried to explain myself as best I could.

That said - I totally confirm what I said at the end of my speech: The “Send only” function should be called “MIRROR SYNCHRONIZATION”! -

IT’S NOT “ONE-WAY SYNCHRONIZATION” (as the phrase “Send only” might suggest) - CONSEQUENTLY THE PHRASE “SEND ONLY” IT’S MISLEADING!

I don’t really understand this part. The distinction between “synchronisation” and “mirror” isn’t always exactly clear, but mirroring would suggest that remote changes are automatically overwritten by the sending side. Syncthing doesn’t support this kind of operation (hence the whole “local additions” and “revert local additions”).

Send Only simply means that this folder is the only source of changes and won’t accept any changes from remote devices. Receive Only is useful if you want to make sure that nothing changed locally (e.g. by mistake or a virus) gets pushed to other devices.

I think it would be useful if you could list clearly in steps what you’re doing, possibly including screenshots showing the whole process.

Ok I give up. Thanks

Please don’t give up! (That is actually a quote from the wonderful song “Don’t give up” by Peter Gabriel.) It seems to me that you want a backup. Syncthing is not a backup tool, but can be a part of a backup solution, where a good start is what you have already: Send Only provider and Receive Only at the NAS side where you can do the actual backup.

Good luck!

2 Likes

I feel your pain - I’ve also had very similar problems with Receive Only and Send Only where a single folder and file in that folder were creating “Local Additions” somehow - and I only speak English :slightly_smiling_face:. And the reset button seemingly did nothing.

The first thing to try is enabling “Ignore Permissions” under the “Advanced” tab of the sync. This may have limited the problem for me, but did not eliminate it.

In my case, I wanted a backup and it was good enough to set both sides to “Send & Receive”, but on the backup side disable deletes. This is done under “Actions > Advanced > Folders” where you will find the name of the folder you are sync-ing. On the English version it’s a checkbox called “Ignore delete”.

If you want a backup then according to my understanding also a deletion should be mirrored to the receive side. At least this is what I would expect.
Also consider that a simple backup doesn’t safe you from loosing data.
What I could recommend is to combine Syncthing with rsync/dirvish. Have Synthing one-way-sync to one folder on the NAS. Then do a backup of this folder, e. g. every night. Have dirvish make hardlinks for identical files instead of full backups. This way it appears as if the files are there for every date they were present in the folder to be backed up. But on the disc of the NAS each version of each file is only stored once.
So you get the current state of the backed up folder for every date you have a backup. If a file is created, it is in the backup beginning that day. If it is changed you automatically get a new version. If it is changed again you get a third version. And if it is deleted it is missing in the backup from that day on. But all three versions are still on your disc, as long as you have at least one backup for each of them. It is similar to Apple’s time machine and it’s very comfortable, doing a restore is nothing more than performing a simple copy operation.

You also get some protection and detection from ransomware:
After the initial backup (which is of course a full backup) your disc space will be going down only very slowly, it eats up only the hardlinks plus the changes in files for each backup. If you realize that suddenly a lot of files have changed (by taking an unusual large amount of disc space for the current backup) then you know something’s definitely wrong. If you can avoid the ransomware infecting your NAS and avoid the backups to be externally changeable (e. g. by a rw-Samba share) so they cannot easily be encrypted, you still have the unaltered backups. Also a good idea is to backup e.g. a Windoze system by a Linux system. The more away from the mainstream you get, the more difficult you make it for the ransomers. They still mostly concentrate on Windoze, so a Linux system is always a good choice (let’s hope it’ll stay that way).
I am running a system sketched like above flawlessly since many year. It is fully automated, you don’t have to care about it (aside from assuring that the backup indeed runs every night and that it is readable). It is not perfect (e. g. your house containing both, the system to be backed up and the backup system, could burn down taking all data and copies of it down) but it is a good start. Also take into account that Syncthing can sync more than two devices, also over the internet. So if you find e. g. two friends you could mutually backup the data of all three of you to three different locations. Very often you don’t want your friends to have a look at your intimate data, will you? So sent them only encrypted version of your files (by using a third tool) instead of unencrypted ones. You see the beauty of Linux? Here you have three different tools, doing their own job but knowing nothing about each other. You pipe them together to result in a solution that’s specifically adapted to your needs. This will make you even more secure but it’s still not perfect. If an atomic war is taking its toll close to you all your data will still be gone. But you can protect from that by finding two kinds of aliens living on two different planets. You could backup… :grinning:
Stop kidding. If an atomic war is happening all of us will probably have other serious problems, won’t we?

2 Likes

Hi all :slight_smile:

I thank you all for explanations and advice.
Unfortunately, Google’s imperfect translation caused misunderstanding. I immediately clarify that I have solved marginal problems and that I have understood that Syncthing is the “SYNCTHING APP” I was looking for and that - among other things - it saves the data exactly as I wanted.

You already know that I am interested in simply “duplicating” on the NAS the contents of some folders in my Android devices to have a copy of redundancy. Stop. The fact that I am using a rifle (Syncthing) to kill mosquitoes is secondary.

Unfortunately I have not found simple, safe and functional programs like Syncthing to do a simple job. So while Syncthing can do a lot more, that’s fine for me for now.

If anything, I was wrong to tackle a question of “nuances” by not knowing English.

The thing that I found unusual (and for what it’s worth, in my humble opinion wrong), is that using the “Send only” options on Android and “Receive only” on the NAS, if I delete a file on Android, the deletion file is also repeated on the NAS. In my language, but also in the NAS operating system, or even in a “Free File Sync” Windows synchronization software, if I use the send only function, the files are NOT deleted! The way of working of Syncthing can be defined “mirroring” or if you prefer, “bilateral” NOT “Send only”!

Again … if I use the “Send Only/Receive only” function in case of one or more modifications of the “source” file I expect to find more copies on the “Receive only” destination. This does not happen in Syncthing with the same options enabled, in fact I will have in the destination, only the last modified version on the source device.

I do not contest the architecture and design choices of the developers and maintainers of Syncthing which works very well and which I am using with satisfaction. I understood how Syncthing works and I adapted! Mine was just a discussion on the semantic meaning of “Send only” which - in Italian - is not what Syncthing does. Syncthing with the functions “Send only/Receive only”: makes a “mirror” copy of the source on a destination.

Cheers :slight_smile:

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.