Skip to content

Harden settings load and save safety#47

Closed
danielchalmers wants to merge 1 commit into
mainfrom
codex/settings-resiliency
Closed

Harden settings load and save safety#47
danielchalmers wants to merge 1 commit into
mainfrom
codex/settings-resiliency

Conversation

@danielchalmers

@danielchalmers danielchalmers commented Jun 11, 2026

Copy link
Copy Markdown
Owner

Summary

Part of #46.

This PR keeps the settings resiliency work narrowly focused on direct data-loss prevention:

  • stops startup from saving the real settings file just to compute CanBeSaved
  • probes writeability with a throwaway temp file in the settings directory
  • treats malformed or empty existing settings files as corruption, not first-run defaults
  • preserves unreadable primary settings files as .corrupt-* snapshots before fallback defaults can be saved
  • disables saving for the run if an unreadable primary file cannot be copied aside
  • writes settings through a same-directory temp file before replacing/moving into the primary path
  • adds deterministic tests for those behaviors and property-level deserialization resilience

Out Of Scope

This intentionally removes the broader pieces from the first draft:

  • no MSI/package changes in this PR
  • no graceful installer close or exit-time save
  • no .lastgood backup/automatic restore flow
  • no settings relocation out of the executable-adjacent directory

The MSI wildcard cleanup is split into a separate PR so it can be reviewed and reverted independently.

Validation

  • dotnet build RadialActions.sln
  • dotnet test RadialActions.sln (68 passed)

This keeps the settings PR focused on direct data-loss prevention. Startup no longer saves the loaded settings object just to determine whether settings can be saved; it now loads settings and probes directory writability with a throwaway file.

When an existing primary settings file is malformed, empty, or unreadable, the load path copies it to a timestamped .corrupt-* snapshot before recovered default settings are allowed to save over the primary path. If the unreadable primary cannot be copied aside, saving is disabled for the run so fallback defaults do not overwrite the only recoverable copy.

Settings writes now go through a temporary file in the same directory and then replace or move into the primary path. That reduces the chance that a shutdown, installer interruption, or write failure leaves a truncated settings file behind.

The tests cover malformed and empty primary files, locked unreadable files, startup probing without rewriting the real file, atomic save cleanup, and property-level deserialization errors preserving unrelated valid settings. The intentionally deferred pieces are installer behavior, graceful close/exit save, settings relocation, and last-known-good automatic restore.
@danielchalmers danielchalmers force-pushed the codex/settings-resiliency branch from 1f0907d to 1dc6ca2 Compare June 11, 2026 16:56
@danielchalmers danielchalmers changed the title [codex] Harden settings resiliency and MSI upgrade safety [codex] Harden settings load and save safety Jun 11, 2026
@danielchalmers danielchalmers changed the title [codex] Harden settings load and save safety Harden settings load and save safety Jun 11, 2026
@danielchalmers

Copy link
Copy Markdown
Owner Author

This is too much

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant