matthiasbeyer
/
imag
1
0
Fork 0
Code Releases Activity

Reword some things on filesystem organization 

Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This commit is contained in:
Matthias Beyer 2019-11-09 17:30:03 +01:00
parent e8f3d26a4b
commit 136b4d3dd9
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/02000-store.md
View File

@ -97,15 +97,13 @@ The "Entries" are stored as files in the "Store", which is a directory the
user has access to. The store may exist in the users Home-directory or any user has access to. The store may exist in the users Home-directory or any
other directory the user has read-write-access to. other directory the user has read-write-access to.
Each module stores its data in an own subdirectory in the store. This is because Each module stores its data in an own subdirectory in the store, by convention.
we like to keep things ordered and clean, not because it is technically
necessary.
We name the path to a file in the store "Store id" or "Storepath" and we often The path to a file in the store is named "Store id" (or short "ID") and we
refer to it by using the store location as root. refer to it by using the store location as root.
So if the store exists in `/home/user/store/`, a file with the storepath So if the store exists in `/home/user/.imag/store/`, a file with the storepath
`example.file` is (on the filesystem) located at `example.file` is (on the filesystem) located at
`/home/user/store/example.file`. `/home/user/.imag/store/example.file`.
By convention, each `libimagentry<name>` and `libimag<name>` module stores its By convention, each `libimagentry<name>` and `libimag<name>` module stores its
entries in in `<name>/`. entries in in `<name>/`.