Therefor introduce the "Header" trait which is implemented on Value for
backwards compatibility.
Make the default_header() function publicly available as
Entry::default_header()
The name of the storeid was duplicated, which caused the tests to fail
from time to time.
This patch fixes the name of the entry which is used to test.
On master, we changed the Store::update() function to do nothing more
than calling Store::_update() and wrapping an error.
On the libimagstore/store-tests branch, we modified the
Store::_update() function to contain an additional flag in the
parameters, whether the File-Lock-Entry internal `precense`-value should
be updated.
This merge commit resolves that conflict.
This is a bugfix for an very particular issue.
Here's what happens:
If we create() an FileLockEntry and then update() it, we are running
into a problem because update() calls _update() which changes the
precense status of a FileLockEntry.
Because update() is _consuming_, the FileLockEntry gets drop()ed
afterwards. This _again_ causes _update() to be called, but with a new
presence status, which is not true in this moment (as the FileLockEntry
is still borrowed, but we already marked it as present).
This patch is a short-term fix. The real problem is, that our Store
interface is consuming. If the Store interface would be non-consuming,
this issue wouldn't happen, as the drop() call would not happen.
I'm rather sure that this patch will not be reverted in the process of
rewriting the Store interface to be non-consuming. But we never know.
This is a bugfix for an very particular issue.
Here's what happens:
If we create() an FileLockEntry and then update() it, we are running
into a problem because update() calls _update() which changes the
precense status of a FileLockEntry.
Because update() is _consuming_, the FileLockEntry gets drop()ed
afterwards. This _again_ causes _update() to be called, but with a new
presence status, which is not true in this moment (as the FileLockEntry
is still borrowed, but we already marked it as present).
This patch is a short-term fix. The real problem is, that our Store
interface is consuming. If the Store interface would be non-consuming,
this issue wouldn't happen, as the drop() call would not happen.
I'm rather sure that this patch will not be reverted in the process of
rewriting the Store interface to be non-consuming. But we never know.
to actually test:
1. get -> Should return Ok(None)
2. create -> Should return Ok(())
3. get -> Should return Ok(Some(_))
4. delete -> Should return Ok(())
5. get -> Should return Ok(None)
This patch fixes the `impl Iterator for GlobStoreIdIterator` which used
the glob() result to fetch the files from the FS, but glob() returns the
absolute pathes (to filesystem root).
We have to strip the `store_path` prefix and use the local part for
building the StoreId object.
This was suggested by Marcel Müller, who also debugged this issue and
found that this snippet was the error.
The problem was, that we had the write-lock when starting the hooks. If
the hook runs into an Err() mapping part where the Entry could already
be drop()ed, Rust tries to be smart and drops the object. As we are
still in the creation code of the entry, this paniced as we still hold
the W-Lock and the drop() tryies to call _update() on the entry, which
also tries to W-lock it.
With the new additional scope, the W-lock gets dropped early and we do
not have this problem anymore.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: Marcel Müller <neikos@neikos.email>
Reported-by: Matthias Beyer <mail@beyermatthias.de>
This introduces the `FoldResut` trait to move from `func(receiver, ...)`
style to `receiver.func(...)` style. Also add a means to pass the
default result explicitly.
As the Aspect execution catches the aborting hooks and returns them, we
cannot have a non-aborting error here, so there is no point in checking
for aborting errors.
