Thank you so much for reporting!

I can reproduce the bug. The problem seems to be specific to the mountpoint /, so this triggers the error:

kdb mount default.toml / toml
kdb set user:/test/abcdef 1
#> Create a new key user:/test/abcdef with string "1"
cat `kdb file user:/test`
est.abcdef = 1
kdb get user:/test                                                                                                                                                                                          
#> Did not find key 'user:/test'
kdb get user:/est/abcdef                                                                                                                                                                                  
#> 1
kdb rm user:/est/abcdef
kdb umount /

but with another mountpoint the problem does not occur:

kdb mount test.toml /test/toml toml 
kdb set user:/test/toml/test/abcdef 1
#> Create a new key user:/test/toml/test/abcdef with string "1"
cat `kdb file user:/test/toml/test/abcdef`                                                                                                                                                         
#> test.abcdef = 1
kdb rm user:/test/toml/test/abcdef                                                                                                                                                                         kdb umount /test/tom

My guess is that it is either a problem introduced in #3555 (keyname overhaul by @kodebach) or this case was simply never tested as toml is not yet being tested as default backend (#2330 @bauhaus93). Can you both take a look please?

Thanks for your confirmation and details.

I'm happy to use any other storage plugin as default for openwrt, but ini has already been removed and toml was recommended. The criteria for a default backend are:

1. no dependency besides libc
2. human readable file format

This certainly could be an error caused by #3555. Other plugins (e.g. dump) had similar issues with cascading keys. I don't have time do any real work on this right now, but I will check again later this week.

@markus2330 are you sure it is just caused by / or does it happen with any root key (e.g. user:/)? The TOML plugin seems to mostly use unescaped names, where cascading vs. non-cascading makes no difference. However, root keys are unique in that they contain an empty unescaped part at the end.

The criteria for a default backend are:

1. no dependency besides libc
2. human readable file format

You could try dump. It is technically human readable as long as all key values are human readable, but I wouldn't call it human-friendly or human-editable. It is however the most basic plugin that supports all of Elektra's features and is very well tested (it is used as the default plugin, with the default compile options).

When writing the initial package for OpenWRT we decided against dump as default storage on purpose: Aside from the human-friendlyness it actually has a dependency besides libc - libstdcpp.

it actually has a dependency besides libc - libstdcpp.

Ah yes, I forgot about that. The C++ dependency is of course not ideal for embedded systems.

I'm now 99% certain this issue is caused only by root-level keys. We should probably add a version of check_kdb_internal_suite that uses a root level key, since they are slightly different since the key name change. In particular, root level keys are the only ones that end with a / in escaped form, which translates to an additional \0 at the end of the unescaped form.

Maybe we should change the (un)escaping again so that user:/ is \x06\x00 instead of \x06\x00\x00. It would make certain sections of code (most importantly keyUnescapedName (key) + keyGetUnescapedNameSize (parent) for relative names) more straightforward. Not sure, if that is worth it though.

I'm now 99% certain this issue is caused only by root-level keys.

#3478 would give certainty.

We should probably add a version of check_kdb_internal_suite that uses a root level key

Yes, I agree. Very possible that other storage plugins face the same issue. Can you create an issue or PR for this?

Maybe we should change the (un)escaping again so that user:/ is \x06\x00 instead of \x06\x00\x00. It would make certain sections of code (most importantly keyUnescapedName (key) + keyGetUnescapedNameSize (parent) for relative names) more straightforward. Not sure, if that is worth it though.

Yes, very good idea. I also don't like the special handling of / keys. Can you create an issue or PR for this?

See #3902, #3903

I'm closing this, since the original issue is fixed. I created #3910 for any future issues that prevent TOML from being used as the default storage plugin.