This is yet another attempt to bring CLI completion to this workspace
project.
It uses the subcommand-libraries implementing the ImagApplication
trait to expose the clap CLI interface. This way, no file import magic
happens, it's all just regular dependencies, which should also work
with a regular `cargo install`.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
To re-add the imag-binary CLI completion, as well as to enable
building a single imag containing all of the subcommands, this commit
introduces an ImagApplication trait to be implemented by all imag
binary crates. The binary crates will be converted to libraries, with
an additional binary target. This enables standalone and single binary
builds.
On its own, this commit doesn't do much, but rather it paves the way
to dynamically interacting with the imag uis/clis using a
library-crate interface.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
After moving an entry, the entry should _not_ be in the cache. This is
just a decision that has to be made, whether we cache the moved entry or
not. I decided to not cache because it is results in less code.
After that check, we get the entry from the backend and then we can
check whether the entry is in the cache, which is then should be.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When moving an entry, what we did is copying the entry inside the
backend abstraction (the hashmap) from one key to another.
But as the entry itself does also encode its location, we actually have
to rewrite the entire entry. This patch fixes this.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is a bugfix for a bug in Store::move_entry_by_id():
The old entry was not removed after the new one was created.
The bug is a bit subtle. The issue was, that the internal cache held
open a reference to the old entry (as StoreEntry object) and when that
object got drop()ed, the contents of the entry were written to disk,
which resulted in the old entry being recreated.
This patch rewrites the function to behave well. The most critical part
is that we do not check whether the old entry is borrowed with
`hsmap.get()` but rather `hsmap.remove()`. The trick here is that the
`StoreEntry` object is dropped in the moment the check is done, clearing
the cached object and flushing it to the backend (the disk).
After that, we continue doing the filesystem operation and the cache is
clean.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
