A proposal for a receive-only folder type


#41

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.


(Jakob Borg) #42

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


(Bruno) #43

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: )


(Jakob Borg) #44

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.


(Peter E) #45

This would be an awesome feature. Please proceed!


#46

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.


(Generalmanager) #47

I’m definately in favor of this proposal, it covers my usecases perfectly. I won’t go into too much detail, as these usecases have been layed out by others already. (Mainly one or more server-style devices which also do versioning and one or more mobile devices owned by one or more people. The servers should never propagate local additions or deletions as they are always accidental).

While I am interested in having per-device/per-folder R/W settings as proposed by @AudriusButkevicius, I am positive that we’d need a very well defined method of finding a global consensus between all devices sharing a folder. This would also require a new UI item to notify anyone of either forced changes or devices which don’t adhere to the consensus.

This would be awesome, as it significantly simplifies managing a bigger p2p setup, but it’s certainly a big step that needs some real thought.

I guess I’ll create a topic on that, as a consensus mechanism is one of the things which could greatly improve ST usability to new or less technical users.

Until we may some day get something like this I’d prefer the simplistic “receive only” approach, as changing R/W settings on every device is already a PITA with the simpler read only + send only options.


(Peter E) #48

Jakob Borg I really like the concept as you have described it. Have you made any progress? Thanks, Peter


(Audrius Butkevicius) #49

It’s just a concept, nobody is working on it.


(Jakob Borg) #50

Yeah. I might though, but step one was to specify it a bit. That feels fairly successful.


(David Roesel) #51

@calmh This sounds like a really useful feature the lack of which would stop many people switching from Resilio Sync. Many of us would really appreciate if this was implemented and allow us to use SyncThing! :slight_smile:


#52

Hello,

My first post here - Syncthing is great for what I’ve seen so far!

On-topic - Would you reckon in scope if after mutual consent (could be receive-only + main host, or it could be rcv-only + all cluster participants) the changes on the receive-only folder are propagated within the cluster?

I already have a use case for such an option. And it could be further expanded furthe with granular file control.


Off-topic and introduction /feel free to disregard/ -

I am currently designing a test implementation for “real-time” sync of a ~1.2TiB iwatched folder across WAN (over dedicated 100MBit line at a 2ms distance) containing over 3.2M directories and 2M files. The test environment is virtualised and I am studying the requirements.

These directories will have Samba running on top. All Samba shares will be accessed by ~30 hosts total. Despite that, collisions will happen very seldom. Writes per day would come at a steady pace, totalling about 3-7GiB/day. Reads range between 10-40GiB/day with possible spikes (irrelevant to the sync). Maximum time tolerance before is approximately one minute.

We will see how it goes. I am optimistic. :slight_smile:


(Audrius Butkevicius) #53

No, this probably requires better structuring on your side splitting read only and read write parts into separate folders. People already can’t use ignores, adding yet another cryptic text box with magical petroglyphs for some magic hybrid folders that can write to some paths but not others is out of the question.


#54

Understandable, that makes sense in a user’s point of view and verges on the side of overcomplicating things.

Regardless, as long as I can provide the necessary infrastructure to fully enable the software and get sane performance, I can start working around it.

Unfortunately I’ve explored various options about restructuring the data as well as other solutions (hello DRBD), but I am limited in my options. Furthermore, the projects are very dynamic and there is always a statistically signifant amount of exceptions to work around case by case. My only option is creating tools, but that requires a lot of project-specific adjustments. But I digress again…

Thanks for the prompt reply!


(Jakob Borg) #55

(Adi Dev) #56

Thanks. Fantastic feature! But… there one flaw - I have a big database of pictures and manuals I would like to share with my colleague, but I don’t trust him enough not to mess my folders. He isn’t a tech geek, I can set up a Syncthing instance for him but I’m certain, he will get interested into the settings, so he can change Receive Only status to something else. Is there a way to prevent that? Cheers.


(Audrius Butkevicius) #57

No, it’s against the design of a distributed system with no authority.


(Clemens) #58

Set your own folder as Sendonly. That way he cannot screw with your data.


(Adi Dev) #59

I need to have this folder send/receive with other machines and as far as I know, you cannot set the same folder twice. @AudriusButkevicius, I understand your concerns, just I thought about scenario when you would like to share your family pics with your parents but you don’t want them to be able to remove or rearrange your albums :wink:


(Audrius Butkevicius) #60

If your family is able to delete pictures without understanding what they are doing, then I doubt they will be able to find a way to access the GUI, and then be able to go into settings and change the folder type from receive only to something else.