It would appear either send-only or receive-only is unidirectional, so I guess both could be called “shoehorning” if either is.
I do think it’s a legitimate desire to have some sites receive only - I’ve done this for years where my iTunes music hierarchy is pulled down receive-only to other machines. I don’t want the other machines diddling with the iTunes structure, so I have those machines marked receive only with BTSync.
I would use Syncthing send only, but I want more of a forced send such that if iTunes changes then other sites are forced to change. That’s what I would imagine receive only can do, when specified on the other side of the relationship.
I recognize that other tools such as rsync can do this. However, once working with Syncthing, it’s awkward to use different competing frameworks at the same time. If purist bi-directional sync is forced too hard, then it’s not clear why “send only” currently exists.
I use it on folders that I share for backup purposes only.[1]
For example, I use Lightroom for photo cataloging on my laptop. The Lightroom catalog gets synced to my file server, “send only” on the Laptop. It never gets changed on the file server, so I never see an out of sync warning or an override button. If I did, it would be a huge red flag that my backup process is in fact not a backup process and would require investigation. It’s still configured that way so that if I fat finger something on the other side, or something unexpected happens, I get the warning rather than changes silently propagating back.
To me, this is a perfectly legitimate use case for Syncthing, obviously. But it depends on some care being taken on the receiving side. The “shoehorning” thing comes into play when the setup described here is not enough, when Syncthing should be made to automatically override local changes all the time, and so on. This is the ongoing discussion in the linked PR and related forum posts.
[1] I know I’ll get pushback on this from a lot of people here on the forum because Syncthing is not a backup software - that’s correct, but it can still be used for it if done correctly, much like rsync. The file server that is on the other side uses ZFS with snapshots every five minutes, hour, day, week, month and year. It replicates to another off site server configured similarly.
Got it. I’m coming to the conclusion that “Send Only” and “Receive Only” may be duplicative. Maybe it’s just which end is specified. I was asking for “Receive Only” on backup side, and you’re using “Send Only” on the end you’re trying to backup. Either way, we’re answering the same purpose.
This is what I understand and recognized the behaviour of the folder type
Send & Receive:
It requires a human to confirm remote changes to be overwritten by a Send Only Folder on the Send Only Folder side.
Additionally, local changes are automaticly distributed/received between all connected folders, which are not a Send Only Folder.
Now, this is what I’d like to use in Syncthing in addition to the “Send & Receive” folder type:
Receive Only (from a device with a Send Only Folder):
The Folder would receive changes automaticly from a Send Only Folder (“master folder”) and requires no human confirmation for any local overwriting or remotely recognition of the changes. Everything changed on the Send Only Folder is silently forced to the Receive Only Folder.
I guess, this is something mentioned here:
But also this is very interesting, because I have some folder, which I don’t want to be updated from other “slave” folders, but only from the “master” Send Only folder:
Regarding “Send Only,” I think I prefer the override button to do it because sometimes I forget and actually want files I put on the destination and I am reminded to move them before doing the override.
I am still hoping for “Receive Only” status of a sync node. Most recently, here is the architecture I’m struggling to implement without it. How would you do this without a “Receive Only” option?
I have multiple work computers that must sync, and then I have a separate computer which aggregates updates from the work computers before being encoded and synchronized off-site.
I need the aggregating computer to never send changes back to the work computers. It must be receive only. I cannot accomplish this by setting the work computers to “Send Only” because among themselves they must be Send/Receive.
It is only the relationship to the aggregating computer that must be 1-way. The aggregating computer needs to Receive only.
I guess, that would be a (expensive, neverending therefore inconvenient) fast moving workaround.
It may work for some days, until the remote filesystem will generate some files/folders which are used by the operating system for whatever purpose.
Say, on a Mac, the .DS_Store or other hidden files/foldes, or somekind of automatic generated thumbnails or whatever-info-files when syncing on NAS to a multimedia folder.
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.
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.
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.
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?
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.
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.
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.
The file server that is on the other side uses ZFS with snapshots every five minutes, hour, day, week, month and year. It replicates to another off site server configured similarly.
