23e0973cdf
Fix some typos found while reading various documents, mostly those relating to the castore. Here is a summary of the edits. - fix broken link between documents in the store and castore directories - clarify expression in castore's data model document that indicates that the *name* of each child node of a directory must be unique across all three lists of children - add missing closing parenthesis in castore's data model document - replace "how" with "what" in the phrase "unclear how a ... would even look like" in castore's why-not-git-trees document - remove unnecessary articles in castore's blobstore chunking document - add missing "y" to "optionall" in eval's compilation of bindings document Change-Id: I1997ea91bb4e9c40abcd81e0cde9405968580ba6 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11763 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su>
50 lines
1.9 KiB
Markdown
50 lines
1.9 KiB
Markdown
# Data model
|
|
|
|
This provides some more notes on the fields used in castore.proto.
|
|
|
|
See `//tvix/store/docs/api.md` for the full context.
|
|
|
|
## Directory message
|
|
`Directory` messages use the blake3 hash of their canonical protobuf
|
|
serialization as its identifier.
|
|
|
|
A `Directory` message contains three lists, `directories`, `files` and
|
|
`symlinks`, holding `DirectoryNode`, `FileNode` and `SymlinkNode` messages
|
|
respectively. They describe all the direct child elements that are contained in
|
|
a directory.
|
|
|
|
All three message types have a `name` field, specifying the (base)name of the
|
|
element (which MUST not contain slashes or null bytes, and MUST not be '.' or '..').
|
|
For reproducibility reasons, the lists MUST be sorted by that name and the
|
|
name MUST be unique across all three lists.
|
|
|
|
In addition to the `name` field, the various *Node messages have the following
|
|
fields:
|
|
|
|
## DirectoryNode
|
|
A `DirectoryNode` message represents a child directory.
|
|
|
|
It has a `digest` field, which points to the identifier of another `Directory`
|
|
message, making a `Directory` a merkle tree (or strictly speaking, a graph, as
|
|
two elements pointing to a child directory with the same contents would point
|
|
to the same `Directory` message).
|
|
|
|
There's also a `size` field, containing the (total) number of all child
|
|
elements in the referenced `Directory`, which helps for inode calculation.
|
|
|
|
## FileNode
|
|
A `FileNode` message represents a child (regular) file.
|
|
|
|
Its `digest` field contains the blake3 hash of the file contents. It can be
|
|
looked up in the `BlobService`.
|
|
|
|
The `size` field contains the size of the blob the `digest` field refers to.
|
|
|
|
The `executable` field specifies whether the file should be marked as
|
|
executable or not.
|
|
|
|
## SymlinkNode
|
|
A `SymlinkNode` message represents a child symlink.
|
|
|
|
In addition to the `name` field, the only additional field is the `target`,
|
|
which is a string containing the target of the symlink.
|