fix(db): stop losing the database pointer, and never lose it silently

An operator spent three hours setting up, accepted the update, and reopened a
program that had forgotten everything. It is the second such report.

The updater is not the culprit — it touches its own exe and nothing else. The
pointer is. config.json is the only record of WHERE the database is, and it was
written with os.WriteFile: truncate, then fill. A process that stops between
those two steps — a crash, a power cut, an update's watchdog force-exiting the
old instance — leaves the file empty. readBootstrap then swallowed the parse
error, returned an empty pointer, and startup read that as "no database chosen":
it created a NEW one at the default path and opened it. Three hours of work
still on disk, and an application presenting itself as freshly installed.

Three changes, in the order they defend:

  - The write is atomic. A temporary file, fsync'd, renamed into place — and a
    rename within a volume cannot publish half a file. The previous contents are
    kept as config.json.bak, because a pointer is a few dozen bytes and an
    evening of configuration is not.
  - A pointer that EXISTS and cannot be read is no longer treated as no pointer.
    It is restored from the backup, and when there is nothing to restore from
    the broken file is KEPT as config.json.broken — it is evidence, and it may
    still be readable by hand.
  - Creating a new, empty settings database in a folder that already holds a
    full one is now said out loud, in the startup log and on screen. Nothing is
    deleted and nothing is guessed — guessing which file is theirs is how the
    wrong one gets opened — but the message names the other file, which is where
    their settings still are.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
This commit is contained in:
2026-09-10 00:14:08 +02:00
co-authored by Claude Opus 5
parent e2fe406445
commit b0a973d390
5 changed files with 247 additions and 4 deletions
+5
View File
@@ -3530,6 +3530,11 @@ export default function App() {
try {
const st = await GetStartupStatus();
if (!st.ok) { setError(`Startup failed: ${st.err}\nDB path: ${st.db_path}`); return; }
// Started, but somewhere that deserves saying out loud — a new, empty
// settings database opened beside a full one. An operator who is not
// told this concludes their configuration was thrown away, when the
// file holding it is sitting right there.
if (st.warn) setError(st.warn);
// First launch (or a never-configured profile): collect the mandatory
// station identity before anything else.
try {
+2
View File
@@ -4578,6 +4578,7 @@ export namespace main {
ok: boolean;
err: string;
db_path: string;
warn: string;
static createFrom(source: any = {}) {
return new StartupStatus(source);
@@ -4588,6 +4589,7 @@ export namespace main {
this.ok = source["ok"];
this.err = source["err"];
this.db_path = source["db_path"];
this.warn = source["warn"];
}
}
export class StationDevice {