Before we extracted the store configuration from the configuration
toml::Value object and passed it to the store.
This is unecessary overhead.
Now we pass the whole configuration object and let the store extract the
required values.
Before the iterator did also yield storeids for directories, which was a
bug.
This change introduces a new if_file() function in the store-internal
backend, which is needed to check whether a path actually points to a
File, be it inmemory or on the real filesystem.
That's because tests might fail if they check via PathBuf::is_file() as
in tests, the entries only exist inmemory.
From the documentation of Walkdir::min_depth():
Set the minimum depth of entries yielded by the iterator.
The smallest depth is 0 and always corresponds to the path given to
the new function on this type. Its direct descendents have depth 1,
and their descendents have depth 2, and so on.
This means that when we started with "/tmp/store", we end up yielding
that exact path in the first iteration. This is exactly what we do _not_
want.
Setting the minimal depth to 1 fixes this bug.
This changes the internal GlobStoreIdIterator to return Result<StoreId>,
which gives us the possibility to aggregate errors in the
Store::retrieve_for_module() function and return them instead of tracing
them from the store.
The changes the internals to actually fetch the whole list of storeids,
which is unfortunate of course, but changing the interface is not an
option here, in my opinion.
At least we're only aggregating pathes, so the memory usage is pretty
low here.
This patch fixes a problem where the Store::delete() function only
checked the store-internal cache whether an entry exists, but not the
Filesystem. After this patch is applied, the Store::delete() function
also checks the filesystem whether the entry exists.
As we rely on the filesystem in Store::entries(), which is a bug and
shouldn't be done, we rewrite this function and use the file_abstraction
framework.
