Sorry if this will be something that’s been discussed previously. But I had an idea reagarding the questionable ignoreDeletes option that might not have been considered before.
Right now it’s a separate boolean option next to the folder type setting. So let’s look at the combinations, semantically:
Send only + ignore deletes: Doesn’t apply, we don’t accept remote changes anyway.
Send & receive + ignore deletes: Clear on receiving (we just don’t carry out the deletion), but ambiguous when other remotes are involved. Should we propagate the deletion event to them? That’s where the current complexity comes from IMHO, because we not only have a mismatch between DB and local files, but also between our local model and what we send to other remotes. I might be pretty wrong on that, but the point is, there’s not a clearly obvious “correct” behavior.
Receive only + ignore deletes: I guess this is what most people use it for (can we deduce that from the UR?) to have some kind of “archiving” or “transfer only” folder relationship between two nodes. When remote deletes happen, the local files should stay there regardless, lying to the rest of the cluster that we had deleted them as well.
The last point sounds quite similar to the “local additions” condition. A file deleted from the global state could effectively be deleted (as if ignoreDeletes was false), then added back as a local addition, not counting toward the global state.
What if we were to replace the ignoreDeletes option with a new folder type “Receive only except deletions”? The semantics would be as described in the previous paragraph, but the implementation would be much simpler. And of course we’d just not delete the file instead of somehow resurrecting it. That way the user will be warned about the (deliberate) out-of-sync state and can examine the difference caused by not accepting deletions via the usual means.
In the end we might even drop the old boolean option for the other two folder types, in version 2.0. And still cater for most (?) use cases where such behavior actually makes sense. I imagine the implementation to be very light and easier to support because of clear semantics.
Does that make any sense? Has it been considered before?
I don’t think this has any implementation advantages; the current implementation of ignore deletes is more or less if ignoreDeletes && file.IsDeleted { return; } in a couple of places, doesn’t get much simpler. There might be clarity advantages to only allowing it in combination with receive only.
Current usage reporting doesn’t have enough info to let us know precisely how it’s used; we only get counters of features enabled, not how they’re combined in individual folders. Even so, someone having ignore deletes + send-receive doesn’t necessarily mean that folder couldn’t have been receive-only either.
I quick look through recent forum threads seems to indicate you’re right in that it’s mostly used in the receive only scenario.
As a humble user, I too fell for the receive-only & ignore deletes trap thinking I was getting backup rather than sync. Perhaps it stems from different use cases, as my primary usage is to “sync” files from one household to another (ie. backup) and there are only a few folders where I actually want to sync on machines in my network (eg. laptop and desktop). I solved the former by using simple file versioning, so the file doesn’t actually get deleted.
So perhaps the solution is one of education - I still don’t understand the intended purpose of receive-only & ignore deletes. And if most people could get what they want with versioning, they would be happy.
You’re still syncing a location to another, but yes, it is TransferThing. Still something I would like without digging it another command-line client. No reason it can’t do both. In my case, I want to transfer files from a seedbox to a local machine, then delete those from the source because it’s limited space. I definitely liked Syncthing better than Resilio, but just doesn’t fit what I want.
My point is that by now we’ve already built OutOfSyncthing with the receive / send only folder types. Yet they are worth being officially supported and recommended for some use cases (very few for my usage pattern actually). While the ignoreDeletes option is a wart we’d like to hide if possible. But if all that’s needed is another special case of “out of sync, deliberately” and we don’t introduce as many risks for trouble and give the user a clear indication of what’s going on, that might lower the support effort.
It’s still not Transferthing, but would allow very easily building that on top. Just check the local additions through the API, move them somewhere else and verify that the folder is back in sync.