diff options
author | Valentin Gagarin <valentin.gagarin@tweag.io> | 2022-04-28 10:18:23 +0200 |
---|---|---|
committer | Valentin Gagarin <valentin.gagarin@tweag.io> | 2022-08-04 12:37:47 +0200 |
commit | 90fc5b41a83575c0bd008868f989b6e1497ce3a5 (patch) | |
tree | 8f64b5d605931f6afc82e6f3a37701a4cc1c7ee4 /doc/manual/src/architecture | |
parent | e5e48593c85d052585ff8a275c54823caf575a9d (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/architecture')
-rw-r--r-- | doc/manual/src/architecture/store/objects.md | 40 |
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. |