55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
|
# libimagref
|
||
|
|
||
|
This library crate contains functionality to generate _references_ within the
|
||
|
imag store.
|
||
|
|
||
|
It can be used to create references to other files on the filesystem (reachable
|
||
|
via a filesystem path). It differs from `libimagentrylink`/external linking as
|
||
|
it is designed exclusively for filesystem references, not for URLs.
|
||
|
|
||
|
A reference can have several properties, for example can a reference track the
|
||
|
content of a filesystem path by hashing the content with a hashsum (SHA1) and
|
||
|
one can check whether a file was changed by that.
|
||
|
As files can get big (think of `debian.iso`) _partial hashing_ is supported
|
||
|
(think of "hash the first 2048 bytes of a file).
|
||
|
|
||
|
The library contains functionality to re-find a moved file automatically by
|
||
|
checking the content hash which was stored before.
|
||
|
|
||
|
Permission changes can be tracked as well.
|
||
|
|
||
|
So this library helps to resemble something like a _symlink_.
|
||
|
|
||
|
## Limits
|
||
|
|
||
|
Please understand that this is _not_ intended to be a version control system or
|
||
|
something like that.
|
||
|
We also can not use _real symlinks_ as we need imag-store-objects to be able to
|
||
|
link stuff.
|
||
|
|
||
|
## Usecase
|
||
|
|
||
|
This library offers functionality to refer to content outside of the store.
|
||
|
It can be used to refer to _nearly static stuff_ pretty easily - think of a
|
||
|
Maildir - you add new mails by fetching them, but you mostly do not remove mails
|
||
|
and if you do you end up with a "null pointer" in the store, which can then be
|
||
|
handled properly.
|
||
|
|
||
|
As this library supports custom hashes (you don't have to hash the full file,
|
||
|
you can also parse the file and hash only _some_ content) this is pretty
|
||
|
flexible.
|
||
|
For example if you want to implement a imag module which tracks a certain kind
|
||
|
of files which constantly change... but the first 5 lines do never change
|
||
|
after the file is created - you can write a custom hasher that only uses the
|
||
|
first 5 lines for the hash.
|
||
|
|
||
|
## Internals
|
||
|
|
||
|
Internally, in the store, the file gets created under
|
||
|
`/ref/<hash of the path to the file to refer to>`.
|
||
|
If the content of the file is hashed, we can still re-find the file via the
|
||
|
content hash (which is stored in the header of the store entry).
|
||
|
|
||
|
The reference object can, after the path was re-found, be updated.
|
||
|
|