Locks: space-owner folder locking behind an instance setting (#395) #398
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lock-folders"
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 #395 (deferred L2 extension from #315).
spaceFolderLockssetting (bool, off by default) + admin checkbox in Basic settings, i18n ×4.filelock.RecordgainsDir;Store.Covering(p)resolves the governing lock: exact match first, then a parent-segment walk for liveDirrecords — one in-memory walk, no I/O. The guard'sdenynow usesCovering, andMkdiris guarded too (creating entries inside a frozen subtree is a write).Dirrecord never covers children (regression-tested).POST /api/v1/lockonly when the setting is on AND the requester owns the containing space (spaceOwnerCached); otherwise the existing 400/new 403 stand. Unlock keeps the holder/admin matrix./spaces/; the chip stays exact-path (only the locked folder shows it, children inherit enforcement silently). Server enforces regardless of what the client shows.Coveringwalk incl. name-prefix bleed; mutation check on ther.Dircondition.Closes #395.