ResourceLockComponentLockForPathParams

Parameters for ResourceLockComponent.lockForPath.

Import:

import type { ResourceLockComponentLockForPathParams } from 'obsidian-dev-utils/obsidian/resource-lock';

Signature:

export interface ResourceLockComponentLockForPathParams

Properties

Property	Type	Description
abortController?	AbortController	An optional AbortController associated with the lock. When a lock indicator is clicked (with any mouse button) and the user confirms an unlock, the "Unlock active note" command runs, or ResourceLockComponent.requestUnlockForPath / requestResourceUnlockForPath is called for the path, this controller is aborted so the operation holding the lock can cancel itself. Unless ResourceLockComponentLockForPathParams.shouldReleaseOnAbort is set, the operation is expected to release the lock in its own cleanup. When omitted, an unlock still releases the lock but cannot cancel the operation that took it.
mode?	ResourceLockMode	The lock scope. 'subtree' also locks every descendant of a folder path; 'file' locks only the exact path. A subtree lock must be released via the returned Disposable (not the explicit ResourceLockComponent.unlockForPath).
operationName	string	A human-readable name of the operation that took the lock (e.g. 'Move selection', 'Merge notes'). It is shown — next to the locking plugin's name — in the unlock confirmation dialog, so the user sees exactly which operation an unlock would cancel.
pathOrFile	PathOrFile	The path or file of the note to lock.
shouldBlockMutations?	boolean	When true, the lock also **blocks vault mutations** of the covered path(s): any attempt to edit, delete, rename, move, or (re)create the resource through the Vault/FileManager API throws a ResourceLockedError. Installed lazily on the first such lock and removed when the last one is released. When false (the default) the lock only makes the editor read-only — legacy behavior, so existing consumers that write to a note they hold an editor lock on are unaffected.
shouldReleaseOnAbort?	boolean	When true, the lock releases itself the moment its ResourceLockComponentLockForPathParams.abortController is aborted, instead of relying on the owning operation to release it in its own cleanup. Use it for a lock held **indefinitely** outside a using scope (so there is no finally to release it) — e.g. a lock that stays until the user explicitly unlocks. Leave it false for a transactional operation that holds the lock through its own abort-driven rollback and releases it via using at scope exit. Has no effect without an ResourceLockComponentLockForPathParams.abortController.

Methods

Method	Returns	Description
onUnlockRequested(this)	void	When provided, this callback is invoked when an unlock of the lock is requested — i.e. when the lock's ResourceLockComponentLockForPathParams.abortController is aborted (by the indicator's "Unlock" menu, the "Unlock active note" command, ResourceLockComponent.requestUnlockForPath, or handleExternalMutation). Use it to clear consumer-side state that shadows the lock (e.g. a pending-operation buffer or a notice) without hand-wiring an abort listener. Fires at most once.