Get desktop application:
View/edit binary Protocol Buffers messages
Metadata stored in sample file dirs as `<dir>/meta`. This is checked against the metadata stored within the database to detect inconsistencies between the directory and database, such as those described in `design/schema.md`. As of schema version 4, the overall file format is as follows: a varint-encoded length, followed by a serialized `DirMeta` message, followed by NUL bytes padding to a total length of 512 bytes. This message never exceeds that length. The goal of this format is to allow atomically rewriting a meta file in-place. I hope that on modern OSs and hardware, a single-sector rewrite is atomic, though POSIX frustratingly doesn't seem to guarantee this. There's some discussion of that here: <https://stackoverflow.com/a/2068608/23584>. At worst, there's a short window during which the meta file can be corrupted. As the file's purpose is to check for inconsistencies, it can be reconstructed if you assume no inconsistency exists. Schema version 3 wrote a serialized DirMeta message with no length or padding, and renamed new meta files over the top of old. This scheme requires extra space while opening the directory. If the filesystem is completely full, it requires freeing space manually, an undocumented and error-prone administrator procedure.
A uuid associated with the database, in binary form. dir_uuid is strictly more powerful, but it improves diagnostics to know if the directory belongs to the expected database at all or not.
A uuid associated with the directory itself.
The last open that was known to be recorded in the database as completed. Absent if this has never happened. Note this can backtrack in exactly one scenario: when deleting the directory, after all associated files have been deleted, last_complete_open can be moved to in_progress_open.
The last run which is in progress, if different from last_complete_open. This may or may not have been recorded in the database, but it's guaranteed that no data has yet been written by this open.
Corresponds to an entry in the `open` database table.
Used in:
Permissions to perform actions. See description in ref/api.md. This protobuf form is stored in user and session rows.