# Name

`nix-store --register-validity` - register store objects as valid

# Synopsis

`nix-store` `--register-validity` [`--reregister`] [`--hash-given`]

# Description

The operation `--register-validity` reads serialised [metadata] for [store objects][store object] from standard input and registers those store objects as [valid][validity] in the [local Nix store][local store].
As with the [traditional (post-build) processing of outputs](@docroot@/store/building.md#traditional-post-build-processing) during building, this command is used when the [file system objects] of the would-be store objects already exist in the local store, but the database does not yet know their metadata.
Running this command catches the database up with the file system, making them bona fide store objects.

The input consists of a sequence of records, one per store object.
Each record has the following format:

```
path
nar-hash    (only with --hash-given)
nar-size    (only with --hash-given)
deriver
number-of-references
reference-1
...
reference-n
```

Here, *path* is the [store path] of the store object to register.
*nar-hash* is the base-16 SHA-256 hash of the path’s [NAR][Nix Archive] serialisation, and *nar-size* is the size of the NAR in bytes.
These two lines are only present when `--hash-given` is specified; otherwise they must be omitted, and Nix computes the NAR hash and size from the store object instead.
*deriver* is the [store path] of the [deriver], the derivation that produced this path, or an empty line if unknown.
*number-of-references* specifies how many [reference] paths follow, which are listed on the subsequent lines.

The input is typically generated by other Nix operations such as [`exportReferencesGraph`](@docroot@/language/advanced-attributes.md#adv-attr-exportReferencesGraph).
Only this textual format is understood; the JSON form that `exportReferencesGraph` produces with [structured attributes](@docroot@/language/advanced-attributes.md#adv-attr-structuredAttrs) is not accepted.
Since the files produced for builders contain no hashes, they must be used without `--hash-given`.
It is the responsibility of the caller to provide a complete [closure].

This is a low-level operation intended for internal use.
Its main use is registering the closure of a system inside an image or chroot being populated with a Nix store, e.g. when building NixOS installation images.

# Options

- `--reregister`

  Register the store objects even if they are already marked as valid in the store.
  Without this flag, already-valid store objects are skipped.

- `--hash-given`

  Expect the NAR hash and size in the input, as described above, instead of computing them from the store objects.

{{#include ./opt-common.md}}

{{#include ../opt-common.md}}

{{#include ../env-common.md}}

[file system objects]: @docroot@/store/file-system-object.md
[local store]: @docroot@/store/types/local-store.md
[metadata]: @docroot@/store/store-object.md#metadata
[store object]: @docroot@/store/store-object.md
[store path]: @docroot@/store/store-path.md
[validity]: @docroot@/glossary.md#gloss-validity
[Nix Archive]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive
[reference]: @docroot@/glossary.md#gloss-reference
[closure]: @docroot@/glossary.md#gloss-closure
[deriver]: @docroot@/glossary.md#gloss-deriver
