v1.9.62

A corrupt settings file no longer blocks every save

v1.9.61 stopped an unparseable settings file from being silently rebuilt from defaults, which was the right protection but left the server unable to write settings at all: every save was refused, and the only way out was deleting the file by hand.

The file is now set aside instead. On startup an unparseable settings file is renamed to settings.json.corrupt-<date> and the settings are restored from the copy in config.db, or from the defaults when there is none. The store is writable again immediately, and the original content is kept for inspection rather than discarded.

What to check

If this happens you will see it in the log at startup:

Settings file was corrupt, moved to /state/settings.json.corrupt-20260907-174504
 - restoring from the BBolt copy or defaults

Check the settings that matter to you afterwards — the peer port above all — since a corrupt file may have cost the most recent changes. The quarantined copy can be inspected or deleted; nothing reads it again.

Writes have been atomic since v1.9.60, so a file should not become corrupt in the first place. This release is the recovery path for files damaged before that, and for damage that comes from outside the server.

Also in this release

• The warning about a state directory that is not on a mounted volume is printed once rather than repeated for each directory underneath it.