aboutsummaryrefslogtreecommitdiff
path: root/doc/manual/src
diff options
context:
space:
mode:
authorValentin Gagarin <valentin.gagarin@tweag.io>2022-04-28 10:18:23 +0200
committerValentin Gagarin <valentin.gagarin@tweag.io>2022-08-04 12:37:47 +0200
commit90fc5b41a83575c0bd008868f989b6e1497ce3a5 (patch)
tree8f64b5d605931f6afc82e6f3a37701a4cc1c7ee4 /doc/manual/src
parente5e48593c85d052585ff8a275c54823caf575a9d (diff)
reword file system objects
- use singular for the "class" - more consistency in type definition - minor fixes in wording
Diffstat (limited to 'doc/manual/src')
-rw-r--r--doc/manual/src/architecture/store/objects.md40
1 files changed, 16 insertions, 24 deletions
diff --git a/doc/manual/src/architecture/store/objects.md b/doc/manual/src/architecture/store/objects.md
index caa00d862..872a209c3 100644
--- a/doc/manual/src/architecture/store/objects.md
+++ b/doc/manual/src/architecture/store/objects.md
@@ -1,40 +1,32 @@
-# Store Objects
+# Store Object
-Data in Nix is chiefly organized into *store objects*.
+Nix organizes the data it manages into *store objects*.
A store object is the pair of
- - A (root) file system object
- - A set of references to store objects
+ - a [file system object](#file-system-object)
+ - a set of [references](#reference) to store objects.
-## File system objects
+## File system object {#file-system-object}
-The Nix store uses a simple filesystem model.
+The Nix store uses a simple file system model.
data FileSystemObject
- = Regular Executable ByteString
- | Directory (Map FileName FSO)
- | SymLink ByteString
-
- data Executable
- = Executable
- | NonExecutable
-
-In particular, every file system object falls into these three cases:
+ = File Executable Data
+ | Directory (Map FileName FileSystemObject)
+ | SymLink Path
+Every file system object is one of the following:
- File: an executable flag, and arbitrary data
+ - Directory: mapping of names to child file system objects
+ - [Symbolic link](https://en.m.wikipedia.org/wiki/Symbolic_link): may point anywhere.
- - Directory: mapping of names to child file system objects.
-
- - 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.
-
-A bare file or symlink as the "root" file system object is allowed.
+ In particular, symlinks pointing outside of their own root file system object, or to a store object without a matching reference, are allowed, but might not function as intended.
+A bare file or symlink can be a root file system object.
-## References
+## Reference {#reference}
-Store objects can refer to both other store objects and themselves.
+A store object can refer to both other store objects and itself.
Self-reference may seem pointless, but tracking them is in fact useful.
We can best explain why later after more concepts have been established.