forked from lix-project/lix
document store paths
update the glossary to point to the new page. since this is a cross-cutting concern, it warrants its own section in the manual. Co-authored-by: John Ericson <git@JohnEricson.me>
This commit is contained in:
parent
4ba8b182be
commit
d7b7a79f3e
|
@ -19,6 +19,7 @@
|
||||||
- [Nix Store](store/index.md)
|
- [Nix Store](store/index.md)
|
||||||
- [File System Object](store/file-system-object.md)
|
- [File System Object](store/file-system-object.md)
|
||||||
- [Store Object](store/store-object.md)
|
- [Store Object](store/store-object.md)
|
||||||
|
- [Store Path](store/store-path.md)
|
||||||
- [Nix Language](language/index.md)
|
- [Nix Language](language/index.md)
|
||||||
- [Data Types](language/values.md)
|
- [Data Types](language/values.md)
|
||||||
- [Language Constructs](language/constructs.md)
|
- [Language Constructs](language/constructs.md)
|
||||||
|
|
|
@ -86,10 +86,13 @@
|
||||||
|
|
||||||
- [store path]{#gloss-store-path}
|
- [store path]{#gloss-store-path}
|
||||||
|
|
||||||
The location of a [store object] in the file system, i.e., an
|
The location of a [store object](@docroot@/store/index.md#store-object) in the file system, i.e., an immediate child of the Nix store directory.
|
||||||
immediate child of the Nix store directory.
|
|
||||||
|
|
||||||
Example: `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
|
> **Example**
|
||||||
|
>
|
||||||
|
> `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
|
||||||
|
|
||||||
|
See [Store Path](@docroot@/store/store-path.md) for details.
|
||||||
|
|
||||||
[store path]: #gloss-store-path
|
[store path]: #gloss-store-path
|
||||||
|
|
||||||
|
|
|
@ -4,7 +4,7 @@ A Nix store is a collection of *store objects* with *references* between them.
|
||||||
A store object consists of
|
A store object consists of
|
||||||
|
|
||||||
- A [file system object](./file-system-object.md) as data
|
- A [file system object](./file-system-object.md) as data
|
||||||
- A set of [store paths](@docroot@/glossary.md#gloss-store-path) as references to other store objects
|
- A set of [store paths](./store-path.md) as references to other store objects
|
||||||
|
|
||||||
Store objects are [immutable](https://en.wikipedia.org/wiki/Immutable_object):
|
Store objects are [immutable](https://en.wikipedia.org/wiki/Immutable_object):
|
||||||
Once created, they do not change until they are deleted.
|
Once created, they do not change until they are deleted.
|
||||||
|
|
69
doc/manual/src/store/store-path.md
Normal file
69
doc/manual/src/store/store-path.md
Normal file
|
@ -0,0 +1,69 @@
|
||||||
|
# Store Path
|
||||||
|
|
||||||
|
Nix implements references to [store objects](./index.md#store-object) as *store paths*.
|
||||||
|
|
||||||
|
Think of a store path as an [opaque], [unique identifier]:
|
||||||
|
The only way to obtain store path is by adding or building store objects.
|
||||||
|
A store path will always reference exactly one store object.
|
||||||
|
|
||||||
|
[opaque]: https://en.m.wikipedia.org/wiki/Opaque_data_type
|
||||||
|
[unique identifier]: https://en.m.wikipedia.org/wiki/Unique_identifier
|
||||||
|
|
||||||
|
Store paths are pairs of
|
||||||
|
|
||||||
|
- A 20-byte digest for identification
|
||||||
|
- A symbolic name for people to read
|
||||||
|
|
||||||
|
> **Example**
|
||||||
|
>
|
||||||
|
> - Digest: `b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z`
|
||||||
|
> - Name: `firefox-33.1`
|
||||||
|
|
||||||
|
To make store objects accessible to operating system processes, stores have to expose store objects through the file system.
|
||||||
|
|
||||||
|
A store path is rendered to a file system path as the concatenation of
|
||||||
|
|
||||||
|
- [Store directory](#store-directory) (typically `/nix/store`)
|
||||||
|
- Path separator (`/`)
|
||||||
|
- Digest rendered in a custom variant of [Base32](https://en.wikipedia.org/wiki/Base32) (20 arbitrary bytes become 32 ASCII characters)
|
||||||
|
- Hyphen (`-`)
|
||||||
|
- Name
|
||||||
|
|
||||||
|
> **Example**
|
||||||
|
>
|
||||||
|
> ```
|
||||||
|
> /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
|
||||||
|
> |--------| |------------------------------| |----------|
|
||||||
|
> store directory digest name
|
||||||
|
> ```
|
||||||
|
|
||||||
|
## Store Directory
|
||||||
|
|
||||||
|
Every [Nix store](./index.md) has a store directory.
|
||||||
|
|
||||||
|
Not every store can be accessed through the file system.
|
||||||
|
But if the store has a file system representation, the store directory contains the store’s [file system objects], which can be addressed by [store paths](#store-path).
|
||||||
|
|
||||||
|
[file system objects]: ./file-system-object.md
|
||||||
|
|
||||||
|
This means a store path is not just derived from the referenced store object itself, but depends on the store the store object is in.
|
||||||
|
|
||||||
|
> **Note**
|
||||||
|
>
|
||||||
|
> The store directory defaults to `/nix/store`, but is in principle arbitrary.
|
||||||
|
|
||||||
|
It is important which store a given store object belongs to:
|
||||||
|
Files in the store object can contain store paths, and processes may read these paths.
|
||||||
|
Nix can only guarantee referential integrity if store paths do not cross store boundaries.
|
||||||
|
|
||||||
|
Therefore one can only copy store objects to a different store if
|
||||||
|
|
||||||
|
- The source and target stores' directories match
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
- The store object in question has no references, that is, contains no store paths
|
||||||
|
|
||||||
|
One cannot copy a store object to a store with a different store directory.
|
||||||
|
Instead, it has to be rebuilt, together with all its dependencies.
|
||||||
|
It is in general not enough to replace the store directory string in file contents, as this may render executables unusable by invalidating their internal offsets or checksums.
|
Loading…
Reference in a new issue