On my server, I have a big second disk mounted at ~/data. My Syncthing repositories on that server are in ~/data/syncthing/data; that is, they’re on that big second disk. My question is this: if that disk fails, or gets unmounted, or something, will syncthing look, say “hey, ~/data is empty! all those files must have been deleted!” and promptly delete them from my other machines too? Because that would be bad. Can I prevent that from happening somehow?
Yep! That’s exactly what’ll happen (if it’s running at the time, or started with the disk unmounted)…
I guess only by setting those nodes to be read only, but then of course they wouldn’t accept any updates at all. Once upon a time there was a separate setting to allow or disallow deletes (apart from updates and new files), but that’s gone and you would probably anyway want “normal” deletes to propagate.
What doesn’t exist, but would be a sane feature, would be a limit on how many files can reasonably be expected to be deleted in a single transaction. For example, if that was set to 25% and more than 25% of the files in a repository were suddenly gone syncthing could draw the conclusion that something catastrophic had happened and ignore the scan results for the time being…
Even simpler would be to simply check for the repository root. If we have an index that says it exists and contains files (i.e. it did at some point, and we are up and running with that assumption), then if we suddenly get a “does not exist”-error on that directory when scanning for changes we assume something bad has happened and wait for it to come back / log an error / whatever.
If we don’t have an index for it (first startup) we can create it, as happens now.
This should work for your usecase (syncthing repo in ~/data/syncthing, ~/data goes away) but not if the repo is ~/data and the disk is mounted in ~/data/photos or whatever.
Yeah. I’m thinking here in terms of protecting against this sort of problem, because it’s totally catastrophic if it happens: my server breaks (losing files on the server) and syncthing them merrily replicates the disaster all over my network and boom, everything’s gone 
I like the idea of trapping “does not exist” on a thing which previously existed, and of “wow a lot has changed; ignore the scan results”… it feels like those two (and probably other) things ought to trip a “I am not sure, I want confirmation” switch somewhere, and then the GUI shows a big red “something weird has happened; please confirm you’ expected it” button to clear the switch and resume syncing. Having this sort of guard around drastic changes would be pretty good for people’s sanity, I think; just have anything dangerous trip the switch and then stop activity on that repo until the switch gets explicitly untripped, perhaps.
Indeed, this happened to me recently. I lost all of my data after I sparked up SyncThing on my home server without the big data volume mounted. I didn’t notice immediately, but a few days later. Luckily I was able to remount the disk and re-populate all the machines, so it wasn’t catastrophic, but it could have been a bit
Huh. That’s painful. ZFS snapshots ftw. But yeah, sounds like this would be an allround useful safety check.