{"version":"2.1.223","anchor":"daemon-lock-can-now-live-in-the-v5-storage-backend","canonical_anchor":"daemon-lock-can-now-live-in-the-v5-storage-backend","heading":"Daemon lock can now live in the v5 storage backend","tier":"soon","area":"Daemon","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223\/e\/daemon-lock-can-now-live-in-the-v5-storage-backend","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.223","markdown":"### Daemon lock can now live in the v5 storage backend\n\nThe background daemon's lock can live in a storage backend instead of a file on disk.\n\n**What**\n\nThe daemon lock can be read, acquired and deleted through the v5 storage backend rather than a file, when a backend handle is passed in.\n\n**Details**\n\n- the read, acquire and delete helpers and the status query all take an optional storage backend argument\n- the lock is a `daemon-lock` state entry written with an ifAbsent precondition, with dedicated error messages and a size cap that clears a too-large lock\n- read failures with ENXIO, EFBIG, ELOOP or ENAMETOOLONG delete the lock rather than throwing\n- the status command and the version-mismatch check now pass the handle through; whether a backend is actually supplied depends on the caller\n- none of the v5 lock strings exist in the previous build\n\n**Evidence**\n\n`[DaemonLock] v5 lock read failed`\n\n- Area: Daemon\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}