{"version":"2.1.267","anchor":"symlinked-settings-path-writes-get-a-fallback-currently-dis","canonical_anchor":"symlinked-settings-path-writes-get-a-fallback-currently-dis","heading":"Symlinked-settings-write fallback is dead code","tier":"soon","area":"Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267\/e\/symlinked-settings-path-writes-get-a-fallback-currently-dis","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.267","markdown":"### Symlinked-settings-write fallback is dead code\n\nA new fallback meant to retry settings writes through symlinked paths never actually runs\n\n**What**\n\nA new helper (`lr`) wraps settings-file writes so that, on a permission-type write failure, it checks a new `Lo()` function and, if `Lo()` returns true, retries the write with `allowSymlink: true` (and `checkParentDir: false`), logging \"Writing settings through symlinked path\". However, `Lo()` is a stub that unconditionally returns false, so the retry branch and its log message can never run.\n\n**Why**\n\nAnyone whose settings file lives behind a symlink and hits this permission error still sees the original failure; the intended fallback to write through the symlinked path does not actually work yet.\n\n- Area: Settings\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}