Initial setup of receive only folder

Development
1

Here’s a rough corner I’m not sure what do about, if anything. When you create a new receive only folder, and there are already files, these are “local modifications”. We show the revert button which, if pressed, will blow everything away.

This makes sense from an internal-technical point of view, it’s how that folder type works. Yet it surprised me when I did it yesterday, and is rather “foot-gun”-ey and so typically something we try to avoid.

Some part of me, even though I know perfectly well how this folder type works, would have expected the existing contents picked up by the initial scan to form the initial global view and thus be fine…

I.e., what happens when you create the folder in normal mode and then change it to receive only after the first scan…

Here’s what I did when I ran into this, if anyone cares about a use case…

I was reorganizing a large photo folder – renaming, moving, and deleting some crap – and when I was done I wanted to sync it to another device that already had the pre-reorganization files. In principle this is a clear rsync -va --delete src dst but I wanted rename handling instead of transferring a hundred gigs so I used Syncthing.

On the source, create a send-only folder with the reorganized files. No sharing yet, just letting it scan.

On the destination, create a receive-only folder where the files already are, with the same folder ID. “Receive only” because I’m being double paranoid about the direction of transfer. No sharing yet, just letting it scan.

Then I was going to let them talk to each other and hit “revert”, but noticed the already lit up revert button on the destination and got scared. :slight_smile: :cold_sweat:

2

I think it’s expected and you should have simply used a send receive type on the receiving end.

3

Could you set the folders up initially as a send/receive and then change them to “Send only” and “receive only” after the initial full sync?

4

I don’t think this is about finding workarounds, I am quite confident Jakob can come up with one :slight_smile:

I would expect it to be perfectly fine to hit revert after letting them talk: I would expect that to work like a pull operation, i.e. replace everything with the global state using the local state for renames etc.
Looking at the implementation that’s not what is going to happen. It will instead delete anything that was only modified locally. I believe that’s not a design necessity, but an area of improvement. It should instead check if there is a valid global version and if so, reset the version vector (like it already does if there’s other counters in the version).

So the foot-gun (revert nuking everything) is only present if there is no global state - not sure that scenario warrants any special solution.

EDIT: Actually even if the solution of “first scan is not receive-only” would be done, wouldn’t that be at least as confusing? If I set a folder to receive-only on creation and then suddenly its files get transferred to other devices, I’d be quite astonished.

5

That’s a fair point (last paragraph).