{"version":"2.1.232","anchor":"settings-writes-report-whether-the-file-was-missing-and-keep","canonical_anchor":"settings-writes-report-whether-the-file-was-missing-and-keep","heading":"Settings writes report whether the file was missing and keep a copy of what they replaced","tier":"internal","area":"Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232\/e\/settings-writes-report-whether-the-file-was-missing-and-keep","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232","markdown":"### Settings writes report whether the file was missing and keep a copy of what they replaced\n\nSettings writes now keep a copy of the exact bytes they replaced and note if no file existed.\n\n**What**\n\nThe result of a settings write now records `missing` when there was no prior file, and on an actual write includes a backup holding the exact bytes it replaced plus a flag saying the write came from a cached copy. These sit alongside the existing did-write, legacy-repair and corrupt fields and the guard that prevents losing stored credentials.\n\n**Details**\n\n- Backup bytes are kept as `replaced: new Uint8Array(...)`.\n- The locked re-read path measures byte length from the cached value directly and reports `missing: !0` in its no-write result.\n\n**Evidence**\n\n`legacyRepair`, `repairingFromCache`\n\n- Area: Settings\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 3\/5"}