fix(settings): stored preferences can be lost when the settings file is shared or briefly unreadable #46

New Issue

2026-11-10T22:07:42Z

james.maes commented

2026-11-10 22:07:42 +00:00

Problem

Preferences are stored in one settings.json per edition, shared by every window and by every process that uses the same data folder (an installed copy and a portable copy, or two builds from different folders).

Two defects, both reproduced with real files and real processes on main (8763ff3):

A read failure is treated as an empty profile. While another handle holds the file exclusively (a scanner, a backup tool, another instance in the middle of a save), a load returns defaults. The next save writes those defaults back. Observed: stored shell theme, document theme, global CSS and recent files replaced by defaults plus the one new change.
Two processes erase each other's changes. Each does load, modify, save with no lock and one shared temporary file name. Observed with two processes recording 8 recent files each: 11 of 16 saves reported failure and 5 of 16 entries survived.

Expected

A change is applied to the latest stored settings under a cross-process lock and replaces the file atomically.
A file that cannot be read is never overwritten; only invalid content counts as corruption, and it is kept aside.
Values and file size read from disk are bounded.

Acceptance

Regression tests with real exclusive handles and concurrent store instances; attempts are counted, not timed.
The two-process experiment keeps every change.
User guide and threat model updated.

## Problem Preferences are stored in one `settings.json` per edition, shared by every window and by every process that uses the same data folder (an installed copy and a portable copy, or two builds from different folders). Two defects, both reproduced with real files and real processes on `main` (8763ff3): 1. **A read failure is treated as an empty profile.** While another handle holds the file exclusively (a scanner, a backup tool, another instance in the middle of a save), a load returns defaults. The next save writes those defaults back. Observed: stored shell theme, document theme, global CSS and recent files replaced by defaults plus the one new change. 2. **Two processes erase each other's changes.** Each does load, modify, save with no lock and one shared temporary file name. Observed with two processes recording 8 recent files each: 11 of 16 saves reported failure and 5 of 16 entries survived. ## Expected - A change is applied to the latest stored settings under a cross-process lock and replaces the file atomically. - A file that cannot be read is never overwritten; only invalid content counts as corruption, and it is kept aside. - Values and file size read from disk are bounded. ## Acceptance - Regression tests with real exclusive handles and concurrent store instances; attempts are counted, not timed. - The two-process experiment keeps every change. - User guide and threat model updated.

james.maes added the bug label 2026-11-10 22:07:42 +00:00

james.maes referenced this issue from a commit

2026-11-10 22:12:10 +00:00

fix(settings): keep stored preferences when the file is shared or unreadable

james.maes referenced a pull request that will close this issue

2026-11-10 22:12:10 +00:00

fix(settings): keep stored preferences when the file is shared or unreadable #47

james.maes referenced this issue from a commit

2026-11-10 22:57:43 +00:00

fix(settings): never set aside a file another program is writing

james.maes referenced this issue from a commit

2026-11-10 23:59:48 +00:00