RunWithApp acquired the process-wide PID lock ($XDG_DATA_HOME/vaultik/vaultik.pid) for every fx-backed command, so a read-only command failed with "already running" while a backup held the lock.
AppOptions now carries a lockMode, and every command declares its mode at the call site:
Mutating commands still mutually exclude; read-only commands run without the lock and are never blocked during a backup.
The acquire/skip decision lives in a small acquireLockIfMutating helper so it is testable without building the fx graph. A new test holds the lock as a mutator, shows a read-only command is not blocked, and shows a second mutator is refused with ErrAlreadyRunning.
Judgement call: snapshot restore is classified read-only. It writes only to the target directory you name and a temporary copy of the snapshot database, never the local index or the remote store, so it does not need the lock; two restores to different targets can now run at once.
The README locking section (added by the documentation pass in #74) is rewritten to describe the new partition.
make check green.
Model: opus-4-8
Closes https://git.eeqj.de/sneak/vaultik/issues/150.
`RunWithApp` acquired the process-wide PID lock (`$XDG_DATA_HOME/vaultik/vaultik.pid`) for every fx-backed command, so a read-only command failed with "already running" while a backup held the lock.
`AppOptions` now carries a `lockMode`, and every command declares its mode at the call site:
- Mutating (take the lock): `snapshot create`, `snapshot purge`, `snapshot remove`, `prune`, `remote nuke`.
- Read-only (no lock): `info`, `snapshot list`, `snapshot verify`, `remote info`, `snapshot restore`.
Mutating commands still mutually exclude; read-only commands run without the lock and are never blocked during a backup.
The acquire/skip decision lives in a small `acquireLockIfMutating` helper so it is testable without building the fx graph. A new test holds the lock as a mutator, shows a read-only command is not blocked, and shows a second mutator is refused with `ErrAlreadyRunning`.
Judgement call: `snapshot restore` is classified read-only. It writes only to the target directory you name and a temporary copy of the snapshot database, never the local index or the remote store, so it does not need the lock; two restores to different targets can now run at once.
The README locking section (added by the documentation pass in https://git.eeqj.de/sneak/vaultik/issues/74) is rewritten to describe the new partition.
`make check` green.
Model: opus-4-8
RunWithApp took the process-wide PID lock for every fx-backed command,
so read-only commands (info, snapshot list, snapshot verify, remote
info) failed with "already running" while a backup held it.
AppOptions now carries a lockMode, and each command declares its mode at
the call site. Only mutating commands (snapshot create, snapshot purge,
snapshot remove, prune, remote nuke) acquire the lock; read-only ones run
without it and are never blocked. snapshot restore is classified
read-only: it writes only to its target directory, not the local index
or remote store. The acquire/skip decision moves to a small
acquireLockIfMutating helper, covered by a test that a read-only command
runs while the lock is held and two mutators still exclude. The README
locking section is rewritten to match.
Model: opus-4-8
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #150.
RunWithAppacquired the process-wide PID lock ($XDG_DATA_HOME/vaultik/vaultik.pid) for every fx-backed command, so a read-only command failed with "already running" while a backup held the lock.AppOptionsnow carries alockMode, and every command declares its mode at the call site:snapshot create,snapshot purge,snapshot remove,prune,remote nuke.info,snapshot list,snapshot verify,remote info,snapshot restore.Mutating commands still mutually exclude; read-only commands run without the lock and are never blocked during a backup.
The acquire/skip decision lives in a small
acquireLockIfMutatinghelper so it is testable without building the fx graph. A new test holds the lock as a mutator, shows a read-only command is not blocked, and shows a second mutator is refused withErrAlreadyRunning.Judgement call:
snapshot restoreis classified read-only. It writes only to the target directory you name and a temporary copy of the snapshot database, never the local index or the remote store, so it does not need the lock; two restores to different targets can now run at once.The README locking section (added by the documentation pass in #74) is rewritten to describe the new partition.
make checkgreen.Model: opus-4-8
PASS
Model: opus-4-8