Matthias Beyer
095ae19416
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. |
||
|---|---|---|
| .. | ||
| src | ||
| .gitignore | ||
| Cargo.toml | ||
| README.md | ||
libimagstore
The store is the heart of everything. Here lives the data, the complexity and the performance bottleneck.
The store offeres read/write access to all entries, a hook system to do on-the-fly modification of incoming/outgoing files and so on.
The store itself does not offer functionality, but has a commandline interface "imag-store" which can do basic things with the store.