Per-file locks: store, storage guard, API, real WebDAV locks, UI (#315) #393
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "file-lock"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements the per-file lock design ratified on #315 (L1-L10).
Backend
internal/storage/filelock: statestore-backed lock store (locks.json, tenth managed state file) with in-memory index, plus aWrapguard decorator between trash and ownermeta. Write/Delete/Rename/Copy-onto are refused for non-holders with the newstorage.ErrLocked; reads are never blocked. Locks follow holder renames, drop on delete and on trashing.user(manual, indefinite) anddav(token-bound, expiring, lazily reaped);appreserved for the co-editing epic.POST/DELETE /api/v1/lock. Unlock rights: holder, admins, owning space owner; breaking another user's lock is audited asbreak-lock(no silent admin write-through - the files_lock CVE lesson).writeErrmapsErrLockedto 423.locked/lockOwner(pure in-memory lookups).no-conflicting-lockon conflicts,lock-token-submittedon locked writes, token-validated UNLOCK, activelock in PROPFIND. A holder's manual lock is not downgraded by a DAV LOCK.UI
data-t="lock"chip "Locked" with holder tooltip, success/failure toasts, i18n x4.Tests: store lifecycle/expiry/persistence, guard verb x identity matrix, rename-carries/trash-drops/delete-removes, full DAV flow (grant, conflict 423, locked PUT 423, holder PUT, lockdiscovery, UNLOCK token validation), manual-lock-blocks-DAV; mutation check on the holder comparison; web extract/check/tests.
Deferred (recorded on #315): admin-configurable expiry cap for user locks (needs a settings row); space-owner folder-locking instance setting; permission-aware hiding of Unlock in the menu (server enforces, client shows the action and surfaces 403).
Closes the third and final part of #315.