Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
kdb spec-mount incompatibilities #2760
Steps to Reproduce the Problem
 mountpoint = mymountpoint.ini [mykey] type = long
sudo kdb mount spec.ini spec/tests/hello ni sudo kdb spec-mount /tests/hello # test 1 kdb set /tests/hello/mykey test # test 2 kdb set user/tests/hello/mykey test # test 3 kdb set /tests/hello/mykey test # test 4 echo "mykey = test" | kdb import /tests/hello/mykey ini
That all 4 tests fail, with an error message from the
Thank you for reporting this problem! It is always important to get feedback about parts that are not working as expected. A special thanks for the detailed description.
test 2 is already reported in #2561
test 3 is a newly found issue. The problem here maybe is that Elektra detects that the key is not changed at all.
test 4 is also a newly found issue but not surprising as cascading import/export are not yet implemented. We should fail in such cases with a "not implemented error". @Piankero in which error category would you see a "not implemented"? Maybe interface error?
#2561 doesn't mention
No the problem actually is
Note: Caching might hide this problem as it would retrieve the whole KeySet. However, I found this bug while working on LCDproc which uses
This was referenced
Jun 9, 2019
Are you sure? I get the same behavior in your 4 cases if I use:
kdb setmeta /tests/hello/mykey type long kdb mount hello.ecf /tests/hello type
But very interesting is that: mmap caching seems to change the behavior of these tests.
@mpranj Do you know what is going on here?
We definitely need more tests with the tools. Especially for caching. (All tests should run with and without caching).
Could you please describe the problem (maybe in a different issue) once again?
The bugs above can imho explained by broken implementation in
Elektra itself of course allows to write broken configs if used improperly, e.g. not getting spec keys, removing spec keys before doing
Btw. there is already a proposal to make every
But imho it is also okay if the tools can circumvent the validation with a
When there is a cache hit (
If this validation should happen in
For me it seems like that cached spec keys suddenly appear in a non-cascading kdbGet that previously were not there, so something like:
kdbGet ("/tests") returns:
then, a later kdbGet ("user/tests") returns the same keys, although this was not the case without caching. Without caching, kdbGet ("user/tests") would only return user keys and the spec plugin would only do a no-op.
If it is an improvement of behavior or not is to be discussed (see #1291).
If this really happens, then it was definitely not intended with my implementation of the cache. I always check that the parentKey is the same or below, which is not the case here. If so, it's definitely a bug and I need to check it.
Of course, but one
As stated above, I originally encountered this problem while doing some stuff with LCDproc and
Like described above, the problem boils down to the fact that
Unfortunately it can: if the previous
Yes, this is because of #2561. If you want validation, you currently need to use cascading keys.
Also without cache hits, kdbGet can return any number of keys. (It might even return all keys).
I need to debunk some myths:
We should write this down somewhere in the docu. What is a good place? FAQ? Is someone reading the FAQ?