Is there a reason why there are no “Receive Only” folders?
I’d like my younger child to get at a set of games on her synchronized computer, but I don’t want anything she does to propagate to others. Am I missing something, or can SyncThing not do this?
Or, I want to access my music library but any mods or deletions I do not want propagating into my master music database. Can SyncThing not do this?
Or, I want to set up a one-way data repository drop that only receives updates but does not send back changes, updates, or deletes.
Reading the docs created more confusion: for a Send Only folder, the phrase “Out of Sync” should probably be reserved to when SyncThing will do something more when able. If the Send Only folder is happy and done and nothing more is going to happen, a different status like “Sends Complete” should be shown (which is still different than “Sync’d” which implies fully bidirectional sync’d has been done). The red button “Override Changes” is a problem because it leaves the user commanding a change on a control panel that does not show what changes are being overridden. The red “Override changes” button means to do nothing locally and actually DO changes on other computers, which seems opposite to the button label. How about if the red button is labelled “Master 1-time Broadcast”? No… that’s too verbose.
BTW, how can a “send only” folder have a red button that forces it to broadcast changes and deletions to everybody else? The send-only status was already propagating local changes out onto the network, so why is the red button appearing at all; isn’t the send node always sending changes to other nodes?
Regarding receive only: Heiko is working on it: #3780.
Regarding the send only folder I can understand some of the confusion, but as you already discovered yourself, it is not easy to find succinct and clear terminology.
As you said yourself, “send only” sends changes when they occur locally. It does not accept changes from remote device. As these changes on the remote device are more recent, they will persist on the remote device. To get all back into sync, the “Override Changes” sets his versions of out of sync items as the current versions, despite them being older. If you manually modify such a file on the “send only” side, it will also be propagated to other device and get into sync.
Keep in mind the send only folder doesn’t automatically override other changes so changes made on other devices will propagate to any other devices in the cluster.
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.
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.
