swarmfile-brlock
swarmfile-brlock drives the engine's byte-range lock API directly. It's a developer/integrator tool - a test client for the same lock primitive that a native worksharing app plugin (the kind of Revit-class CAD/BIM integration that needs to lock only the elements one person is editing, not an entire file) would implement against. It is not something a typical end user runs day to day.
For the conceptual introduction to byte-range locking and how it differs from a whole-file entry lock, see Working with Files.
Global flags#
| Flag | Description |
|---|---|
--cache-dir | Engine cache dir to connect against |
acquire#
Acquire an exclusive byte-range lock.
| Flag | Description |
|---|---|
--entry-id | Entry to lock a byte range on |
--offset | Start offset, in bytes (u64). Default 0 |
--length | Length of the range, in bytes (u64). Default 0, which means "to end of file," not a zero-length range |
--handle-ref | Handle the lock is tied to |
release-handle#
Release every lock tied to a handle ref.
| Flag | Description |
|---|---|
--handle-ref | Handle whose locks should all be released |
Example: acquire and release a range#
A plugin integration would typically acquire a range around the elements being edited, hold it for the duration of the edit, and release everything tied to its handle on close - this simulates that sequence from the command line:
swarmfile-brlock acquire --entry-id ent_9f2a --offset 4096 --length 512 --handle-ref plugin-session-1
# ...edit is in progress, range is locked...
swarmfile-brlock release-handle --handle-ref plugin-session-1
Releasing by handle ref rather than by individual range means a plugin doesn't need to track every range it acquired - closing out a session releases everything that session took.