From 631ca18ee62502dd2e51a8f3c9e2ab656b8382ec Mon Sep 17 00:00:00 2001 From: Valentin Gagarin Date: Tue, 21 Jun 2022 14:08:50 +0200 Subject: [PATCH] reword notes on copying clarify that we are copying between different stores. we have not introduced that notion or why it would be interesting, but for now it should be fine to keep it in context of the store directory. we could move that later to a more detailed explanation of different store types. --- doc/manual/src/architecture/store/path.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/manual/src/architecture/store/path.md b/doc/manual/src/architecture/store/path.md index 2cedc4234..3f2a4bbff 100644 --- a/doc/manual/src/architecture/store/path.md +++ b/doc/manual/src/architecture/store/path.md @@ -42,7 +42,7 @@ 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](store.md#closure) if store paths do not cross store boundaries. -Therefore one can only copy store objects if +Therefore one can only copy store objects to a different store if - the source and target stores' directories match @@ -50,8 +50,9 @@ Therefore one can only copy store objects if - the store object in question has no references, that is, contains no store paths. -To move a store object to a store with a different store directory, 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 break internal offsets or content hashes. +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. # Digest {#digest}