quickdudley/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity

Improve store path section

Browse source
This commit is contained in:
John Ericson 2022-04-18 22:56:21 -04:00 committed by Valentin Gagarin
parent b4df351880
commit 55b437b551
2 changed files with 29 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/manual/src/design/store/objects.md
View file

@ -17,7 +17,7 @@ In particular, every file system object falls into these three cases:
- Symlink: may point anywhere. - Symlink: may point anywhere.
In particular, Symlinks that do not point within the containing root file system object or that of another store object referenced by the containing store object are allowed, but might not function as intended. In particular, symlinks that do not point within the containing root file system object or that of another store object referenced by the containing store object are allowed, but might not function as intended.
A bare file or symlink as the "root" file system object is allowed. A bare file or symlink as the "root" file system object is allowed.

37
doc/manual/src/design/store/paths.md
View file

@ -2,18 +2,15 @@
A store path is a pair of a 20-byte digest and a name. A store path is a pair of a 20-byte digest and a name.
Historically it is the triple of those two and also the store directory, but the modern implementation's internal representation is just the pair.
This change is because in the vast majority of cases, the store dir is fully determined by the context in which the store path occurs.
## String representation ## String representation
A store path is rendered as the concatenation of A store path is rendered as the concatenation of
- the store directory - a store directory
- a path-separator (`/`) - a path-separator (`/`)
- the digest rendered as Base-32 (20 bytes becomes 32 bytes) - the digest rendered as Base-32 (20 arbitrary bytes becomes 32 ASCII chars)
- a hyphen (`-`) - a hyphen (`-`)
@ -21,14 +18,32 @@ A store path is rendered as the concatenation of
Let's take the store path from the very beginning of this manual as an example: Let's take the store path from the very beginning of this manual as an example:
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/ /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
This parses like so: This parses like so:
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/ /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
store dir digest name store dir digest name
We then can discard the store dir to recover the conceptual pair that is a store path:
{
digest: "b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z",
name: "firefox-33.1",
}
### Where did the "store directory" come from?
If you notice, the above references a "store directory", but that is *not* part of the definition of a store path.
We can discard it when parsing, but what about when printing?
We need to get a store directory from *somewhere*.
The answer is, the store directory is a property of the store that contains the store path.
The explanation for this is simple enough: a store is notionally mounted as a directory at some location, and the store object's root file system likewise mounted at this path within that directory.
This does, however, mean the string representation of a store path is not derived just from the store path itself, but is in fact "context dependent".
## The digest ## The digest
The calculation of the digest is quite complicated for historical reasons. The calculation of the digest is quite complicated for historical reasons.
@ -39,10 +54,14 @@ Some of the details will be saved for later.
Store paths are either content-addressed or "input-addressed". Store paths are either content-addressed or "input-addressed".
Content addressing means that the digest ultimately derives from referred store object's file system data and references, and thus can be verified (if one knows how it was calculated). Content addressing means that the digest ultimately derives from referred store object's file system objects and references, and thus can be verified.
There is more than one *method* of content-addressing, however.
Still, if one does know the the content addressing schema that was used,
(or guesses, there isn't that many yet!)
one can recalcuate the store path and thus verify the store object.
Input addressing means that the digest derives from how the store path was produced -- the "inputs" and plan that it was built from. Input addressing means that the digest derives from how the store path was produced -- the "inputs" and plan that it was built from.
Store paths of this sort can not be validated from the content of the store object. Store paths of this sort can *not* be validated from the content of the store object.
Rather, the store object might come with the store path it expects to be referred to by, and a signature of that path, the contents of the store path, and other metadata. Rather, the store object might come with the store path it expects to be referred to by, and a signature of that path, the contents of the store path, and other metadata.
The signature indicates that someone is vouching for the store object really being the results of a plan with that digest. The signature indicates that someone is vouching for the store object really being the results of a plan with that digest.