mirror of
https://github.com/NixOS/nix
synced 2025-07-07 01:51:47 +02:00
manual: Edit
This commit is contained in:
parent
2aa6e0f084
commit
1e00d14c29
8 changed files with 55 additions and 27 deletions
|
@ -28,7 +28,7 @@ With all currently-supported store object content-addressing methods, the file s
|
|||
|
||||
### References
|
||||
|
||||
#### References to other store object#### References to other store objectss
|
||||
#### References to other store objects
|
||||
|
||||
With all currently supported store object content addressing methods,
|
||||
other objects are referred to by their regular (string-encoded-) [store paths][Store Path].
|
||||
|
@ -44,28 +44,28 @@ Self-references however cannot be referred to by their path, because we are in t
|
|||
> which is computationally infeasible.
|
||||
> As far as we know, this is equivalent to finding a hash collision.
|
||||
|
||||
Instead we have a "has self reference" boolean, which end up affecting the digest:
|
||||
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store objects own store path in the digested data is replaced with a [sentinal value](https://en.wikipedia.org/wiki/Sentinel_value).
|
||||
Instead we have a "has self-reference" boolean, which ends up affecting the digest:
|
||||
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
|
||||
The hashes of these modified input streams are used instead.
|
||||
|
||||
When validating the content-address of a store object after the fact, the above process works as written.
|
||||
When validating the content address of a store object after the fact, the above process works as written.
|
||||
However, when first creating the store object we don't know the store object's store path, as explained just above.
|
||||
We therefore, strictly speaking, do not know what value we will be replacing with the sentinental value in the inputs to hash functions.
|
||||
What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was choosen when the data was created).
|
||||
That provisional store path is instead what is replaced with the sentinal value, rather than the final store object which we do not yet know.
|
||||
What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was chosen when the data was created).
|
||||
That provisional store path is instead what is replaced with the sentinel value, rather than the final store object which we do not yet know.
|
||||
|
||||
> **Design note**
|
||||
>
|
||||
> It is an informal property of content-addressed store objects that the choice of provisional store path should not matter.
|
||||
> In other words, if a provisional store object is prepared in the same way except for the choice of provision store path, the provisional data need not be identical.
|
||||
> But, after the sentinal value is substituted in place of each provisional store object's provision store path, the final so-normalized data *should* be identifical.
|
||||
> But, after the sentinel value is substituted in place of each provisional store object's provision store path, the final so-normalized data *should* be identical.
|
||||
>
|
||||
> If, conversely, the data after this normalization process is still different, we'll compute a different content-address.
|
||||
> The method of preparing the provisional self-referenced data has *failed* to be deterministic in the sense of not *leaking* the choice of provisional store path --- a choice which is supposed to be arbitrary --- into the final store object.
|
||||
>
|
||||
> This property is informal because at this stage, we are just described store objects, which have no formal notion of their origin.
|
||||
> Without such a formal notion, there is nothing to formally accuse of being insufficiently deterministic.
|
||||
> Later in this chapter, when we cover [derivations](@docroot@/store/derivation/index.md), we will have a chance to make this a formal property, not of content-addressed store objects themselves, but of derivations that *produce* content-addressed store objects.
|
||||
> Where we cover [derivations](@docroot@/store/derivation/index.md), we will have a chance to make this a formal property, not of content-addressed store objects themselves, but of derivations that *produce* content-addressed store objects.
|
||||
|
||||
### Name and Store Directory
|
||||
|
||||
|
@ -88,7 +88,7 @@ References are not supported: store objects with flat hashing *and* references c
|
|||
|
||||
This also uses the corresponding [Flat](../file-system-object/content-address.md#serial-flat) method of file system object content addressing.
|
||||
|
||||
References to other store objects are supported, but self references are not.
|
||||
References to other store objects are supported, but self-references are not.
|
||||
|
||||
This is the only store-object content-addressing method that is not named identically with a corresponding file system object method.
|
||||
It is somewhat obscure, mainly used for "drv files"
|
||||
|
@ -99,7 +99,7 @@ Prefer another method if possible.
|
|||
|
||||
This uses the corresponding [Nix Archive](../file-system-object/content-address.md#serial-nix-archive) method of file system object content addressing.
|
||||
|
||||
References (to other store objects and self references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
|
||||
References (to other store objects and self-references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
|
||||
|
||||
### Git { #method-git }
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue