File Locking
Memvid uses OS-level file locks to manage concurrent access:Lock Behavior
- Writers take an exclusive
FileLock - Readers share a read lock (multiple concurrent readers allowed)
- Locks are released when the
Memvidhandle is dropped
Checking Lock Status
CLI commands for inspecting locks:Verification
Verify file integrity with the core API:Verification Checks
The verification report includes:| Check | Description |
|---|---|
TimeIndexRead | Time index readable (or skipped if disabled) |
TimeIndexEntryCount | Track entry count matches manifest |
TimeIndexSortOrder | Deep mode: timestamps sorted |
LexIndexDecode | Lexical index readable (or skipped if disabled) |
VecIndexDecode | Vector index readable (or skipped if disabled) |
WalPendingRecords | No uncommitted WAL records |
FrameCountConsistency | Stats match TOC frame count |
Doctor (Repair)
Repair corrupted or damaged files:Doctor Report
The doctor command returns a report with:- Findings: Issues detected (INFO, WARN, ERROR severity)
- Planned Actions: Repairs that will be performed
- Status: Result of each repair action
Single-File Verification
Memvid enforces the “single-file guarantee” at open/create time. If it detects sidecars (e.g.notes.mv2-wal), it fails with MemvidError::AuxiliaryFileDetected.
memvid verify-single-file <file>.
CLI Commands
The CLI exposes these APIs:Error Handling
The core API exposes structured errors viaMemvidError:
Best Practices
Concurrent Access
- Use read-only mode for queries to allow concurrent readers
- Keep write sessions short to minimize lock contention
- Handle LockedError gracefully with retry logic
Integrity Maintenance
- Verify periodically (weekly or after large ingestions)
- Run doctor after crashes or power failures
- Vacuum after bulk deletions to reclaim space