{"version":"2.1.223","anchor":"daemon-lock-and-auto-update-lock-gained-storage-backend-impl","canonical_anchor":"daemon-lock-and-auto-update-lock-gained-storage-backend-impl","heading":"Daemon lock and auto-update lock gained storage-backend implementations","tier":"internal","area":"Storage Backend","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223\/e\/daemon-lock-and-auto-update-lock-gained-storage-backend-impl","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223","markdown":"### Daemon lock and auto-update lock gained storage-backend implementations\n\nLock files that stop two sessions clashing can now live in a storage backend instead of on disk.\n\n**What**\n\nAcquiring, reading, replacing and releasing the daemon lock, plus the auto-updater's stale-lock detection and release, now each have a storage-key branch alongside the original file-based logic.\n\n**Details**\n\n- acquisition uses an `ifAbsent` write with a umask-derived mode; staleness is decided from stat; release deletes the key\n- lock-contention telemetry codes trigger a re-read and one retry before the acquisition fails\n- the file-based path is still present and is what runs without a backend\n\n**Evidence**\n\n`[DaemonLock] Failed to acquire daemon lock: `\n\n- Area: Storage Backend\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 0\/5"}