mirror of
https://github.com/syncthing/syncthing.git
synced 2024-11-16 10:28:49 -07:00
488444354b
So, when first implementing the database layer I added panics on every unexpected error condition mostly to be sure to flush out bugs and inconsistencies. Then it became sort of standard, and we don't seem to have many bugs here any more so the panics are usually caused by things like checksum errors on read. But it's not an optimal user experience to crash all the time. Here I've weeded out most of the panics, while retaining a few "can't happen" ones like errors on marshalling and write that we really can't recover from. For the rest, I'm mostly treating any read error as "entry didn't exist". This should mean we'll rescan the file and correct the info (if scanning) or treat it as a new file and do conflict handling (when pulling). In some cases things like our global stats may be slightly incorrect until a restart, if a database entry goes suddenly missing during runtime. All in all, I think this makes us a bit more robust and friendly without introducing too many risks for the user. If the database is truly toast, probably many other things on the system will be toast as well... GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/4118 |
||
|---|---|---|
| .. | ||
| testdata | ||
| .gitignore | ||
| benchmark_test.go | ||
| blockmap_test.go | ||
| blockmap.go | ||
| concurrency_test.go | ||
| debug.go | ||
| leveldb_dbinstance.go | ||
| leveldb_test.go | ||
| leveldb_transactions.go | ||
| leveldb.go | ||
| namespaced_test.go | ||
| namespaced.go | ||
| set_test.go | ||
| set.go | ||
| structs.go | ||
| structs.pb.go | ||
| structs.proto | ||