Libelektra: caché: sistema de exportación kdb

¿Por supuesto, por qué no? También exporta la versión y otras cosas que no son útiles para la importación. Puede agregar --without-elektra para evitar exportar estas partes.

Para el grabador de shell, también esperaría que solo se haga una copia de seguridad y se restaure la parte dada.

¿Por supuesto, por qué no?

¿ kdbSet elimina de alguna manera? Parece incorrecto serializar estas claves, cuando están codificadas mediante una parte especial de las funciones de obtención del complemento ...

Para obtener información sobre la versión, kdbSet comprueba si son idénticos e ignora kdbSet si lo son. De lo contrario, se genera un error.

Para los módulos (iirc) no hay kdbSet, por lo que las claves para establecer simplemente se ignoran. Iirc, el complemento "constants" tiene el mismo comportamiento. Normalmente se monta en system / info / elektra y no en system / elektra. ¿Quizás deberíamos cambiar eso para que --without-elektra más útil?

Pero de todos modos: ambos comportamientos (ignorar y verificar claves idénticas) no deberían dañar una importación.

Entonces, para la situación actual de la bastante inestable Elektra, tiene mucho sentido: las importaciones de system / elektra se rechazan a menos que la versión sea idéntica. Para evitar este error, se puede pasar --without-elektra .

Después de la 1.0, podemos estar más relajados y aceptar importaciones de la versión 1.0 o superior de Elektra. ( @mpranj ¿qué piensas?)

El texto necesita ser adaptado entonces, actualmente es:

kdb import system < sys
Sorry, module kdb issued the error C01320:
Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version/constants/KDB_VERSION_MICRO (expected system/elektra/version/constants/KDB_VERSION_MICRO) was tried to be modified to '1' (expected '2')

De todos modos, su pregunta da una idea de cómo podemos mejorar la documentación de --without-elektra . La idea de --without-elektra en el contexto de la importación / exportación es que:

1. todas las internas de Elektra se exportan pero luego también tenemos la verificación de versión para no estropear Elektra.
2. no importa / exporta internas de Elektra, por lo que la versión de Elektra no importa (solo la versión del complemento de almacenamiento lo hace)

Después de 1.0 podemos estar más relajados

Estoy de acuerdo con las sugerencias.

Como mencionó @kodebach , de alguna manera es extraño que esto haya aparecido justo ahora en el # 3115 y no haya aparecido antes. Si bien la adición de --without-elektra probablemente debería haber estado allí en primer lugar para la copia de seguridad y restauración, todavía parece que el RP cambió algo de comportamiento.

@kodebach, ¿ Postcondition of backend was violated: drop key [...] not belonging to [...] ) mientras que el caché no se implementó correctamente.

¿Activaste la caché de nuevo para esas pruebas?

Sí, la caché está completamente habilitada.

para que pueda arreglar mmapstorage y cache

mmapstorage ya funciona. Resulta que tenía un key lugar de ukey alguna parte.

La caché también parece funcionar, aparte del problema con la prueba de desmontaje global. La última vez que verifiqué, el error no ocurrió cuando el caché no está compilado.

Cambié partes de kdbGet , elektraCacheGet y funciones relacionadas. Es probable que haya roto algo, pero dado que las cosas que cambié probablemente tengan que cambiarse de nuevo después del número 2969, no creo que debas echar un vistazo ahora mismo.

Está bien. Sugiero que si el caché + mmapstorage causa los problemas, simplemente lo mantenga desactivado hasta el final y lo activamos para adaptarlo.

El PR es un cambio bastante fundamental, por lo que será mucho más fácil si no se queda atascado debido a algún comportamiento de caché roto. Cuando esté básicamente listo, simplemente active la caché nuevamente y haga ping para que pueda echar un vistazo y arreglar el resto.

@mpranj : Te lo

No puedo reproducir nada similar en el master actual. No puedo hacer mucho allí a menos que alguien sepa cómo reproducirlo allí, pero sospecho que no está presente en el maestro.

En la rama de # 3115 obtengo los errores como se describe. @kodebach, ¿ debería ir allí e intentar arreglar las cosas relacionadas con la caché además de sus cambios o es demasiado pronto para trabajar además de eso? ¿Qué tan doloroso es volver a basar la rama del maestro actualmente (complemento previo al backend)?

Creo que no vale la pena trabajar en el # 3115 hasta que el # 2969 y los RP relacionados se fusionen. Después de eso, volveré a basar y tratar de terminar el PR. Me gustaría rebasar lo menos posible, porque básicamente tienes que verificar todas las confirmaciones para cualquier cosa que dependa de la sintaxis de los nombres de clave para garantizar una rebase adecuada.

Si lo desea, por supuesto, puede buscar el error en la versión actual del PR. Sin embargo, por lo que recuerdo, probé esto en master antes de crear el problema, por lo que tal vez se haya solucionado mientras tanto.

Creo que no vale la pena trabajar en el # 3115 hasta que el # 2969 y los RP relacionados se fusionen.

¡Está bien, gracias! ¡Entonces esperemos y verifiquemos este problema después de que se fusionen los RP relacionados!

¿Es posible etiquetar problemas de alguna manera que están esperando algunos RP? Cambié el título por ahora.

De hecho, logré reproducir esto en master hoy. Específicamente, construí scripts/docker/fedora/32/Dockerfile (técnicamente desde # 3447 no desde master , pero el archivo es el mismo y completamente independiente). Luego comencé un contenedor con

docker run -it -w /home/jenkins elektra-fedora-32:latest

y dentro del contenedor corrían las siguientes líneas:

git clone https://github.com/ElektraInitiative/libelektra
cd libelektra && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DKDB_DB_SPEC="$PWD/config/spec" -DKDB_DB_SYSTEM="$PWD/config/system" -DKDB_DB_USER="cdbg-1/.config" -DCMAKE_INSTALL_PREFIX="$PWD/install" -DINSTALL_SYSTEM_FILES=OFF -DENABLE_DEBUG=ON -DENABLE_LOGGER=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DPLUGINS="ALL;-lua;-ccode;-tcl" -DBINDINGS="ALL" -DCOMMON_FLAGS="-Werror"
make -j 24
bin/kdb export system toml

El resultado del último comando fue:

elektra.modules.cache = "cache plugin waits for your orders"
elektra.modules.cache.exports = ""
elektra.modules.cache.exports.close = "(binary)"
elektra.modules.cache.exports.get = "(binary)"
elektra.modules.cache.exports.open = "(binary)"
elektra.modules.cache.exports.set = "(binary)"
elektra.modules.cache.infos = "Information about the cache plugin is in keys below"
elektra.modules.cache.infos.author = "Mihael Pranjic <[email protected]>"
elektra.modules.cache.infos.licence = "BSD"
elektra.modules.cache.infos.metadata = ""
elektra.modules.cache.infos.needs = ""
elektra.modules.cache.infos.placements = "pregetcache postgetcache"
elektra.modules.cache.infos.provides = ""
elektra.modules.cache.infos.recommends = ""
elektra.modules.cache.infos.status = "maintained unittest shelltest specific global"
elektra.modules.cache.infos.version = 1
elektra.modules.dump = "dump plugin waits for your orders"
elektra.modules.dump.config.needs.fcrypt.textmode = 0
elektra.modules.dump.exports = ""
elektra.modules.dump.exports.get = "(binary)"
elektra.modules.dump.exports.serialise = "(binary)"
elektra.modules.dump.exports.set = "(binary)"
elektra.modules.dump.exports.unserialise = "(binary)"
elektra.modules.dump.infos = "Information about the dump plugin is in keys below"
elektra.modules.dump.infos.author = "Markus Raab <[email protected]>"
elektra.modules.dump.infos.licence = "BSD"
elektra.modules.dump.infos.metadata = ""
elektra.modules.dump.infos.needs = ""
elektra.modules.dump.infos.placements = "getstorage setstorage"
elektra.modules.dump.infos.provides = "storage/dump storage dump"
elektra.modules.dump.infos.recommends = ""
elektra.modules.dump.infos.status = "productive maintained conformant unittest tested nodep -1000 default"
elektra.modules.dump.infos.version = 1
elektra.modules.list = "list plugin waits for your orders"
elektra.modules.list.exports = ""
elektra.modules.list.exports.addPlugin = "(binary)"
elektra.modules.list.exports.close = "(binary)"
elektra.modules.list.exports.deferredCall = "(binary)"
elektra.modules.list.exports.editPlugin = "(binary)"
elektra.modules.list.exports.error = "(binary)"
elektra.modules.list.exports.findplugin = "(binary)"
elektra.modules.list.exports.get = "(binary)"
elektra.modules.list.exports.mountplugin = "(binary)"
elektra.modules.list.exports.open = "(binary)"
elektra.modules.list.exports.set = "(binary)"
elektra.modules.list.exports.unmountplugin = "(binary)"
elektra.modules.list.infos = "Information about the list plugin is in keys below"
elektra.modules.list.infos.author = "Thomas Waser <[email protected]>"
elektra.modules.list.infos.licence = "BSD"
elektra.modules.list.infos.needs = ""
elektra.modules.list.infos.placements = "pregetstorage procgetstorage postgetstorage postgetcleanup presetstorage presetcleanup precommit postcommit prerollback postrollback"
elektra.modules.list.infos.provides = ""
elektra.modules.list.infos.status = "unittest nodep libc configurable global"
elektra.modules.list.infos.version = 1
elektra.modules.resolver_fm_hpu_b = "resolver_fm_hpu_b plugin waits for your orders"
elektra.modules.resolver_fm_hpu_b.constants = ""
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_BASE = "fm"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_SYSTEM = "b"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_USER = "hpu"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_DIR = ".dir"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_HOME = "/home"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SPEC = "/home/jenkins/libelektra/build/config/spec"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SYSTEM = "/home/jenkins/libelektra/build/config/system"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_USER = "cdbg-1/.config"
elektra.modules.resolver_fm_hpu_b.exports = ""
elektra.modules.resolver_fm_hpu_b.exports.checkfile = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.close = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.commit = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.error = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.filename = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.freeHandle = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.get = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.open = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.set = "(binary)"
elektra.modules.resolver_fm_hpu_b.infos = "All information you want to know is in keys below"
elektra.modules.resolver_fm_hpu_b.infos.author = "Markus Raab <[email protected]>"
elektra.modules.resolver_fm_hpu_b.infos.licence = "BSD"
elektra.modules.resolver_fm_hpu_b.infos.needs = ""
elektra.modules.resolver_fm_hpu_b.infos.placements = "rollback getresolver setresolver commit"
elektra.modules.resolver_fm_hpu_b.infos.provides = "resolver"
elektra.modules.resolver_fm_hpu_b.infos.status = "productive maintained specific unittest tested libc nodep configurable default"
elektra.modules.resolver_fm_hpu_b.infos.version = 1
elektra.version = "Below are version information of the Elektra Library you are currently using"
elektra.version.constants = ""
elektra.version.constants.KDB_VERSION = "0.9.2"
elektra.version.constants.KDB_VERSION_MAJOR = 0
elektra.version.constants.KDB_VERSION_MINOR = 9
elektra.version.constants.KDB_VERSION_PATCH = 2
elektra.version.constants.SO_VERSION = 4
elektra.version.infos = "All information you want to know"
elektra.version.infos.author = "Markus Raab <[email protected]>"
elektra.version.infos.description = "Information of your Elektra Installation"
elektra.version.infos.licence = "BSD"
elektra.version.infos.version = 1

(NOTA: eliminé las claves .description de la salida, porque contienen la cadena ``` y, por lo tanto, rompen el formato de Markdown de Github)

En mi opinión, la salida debería estar vacía, ya que todas las claves se derivan de la instalación específica de Elektra y nunca deberían importarse a ningún KDB. Posiblemente, exportar las claves version.constants podría tener sentido, si kdb import ignora correctamente (las otras claves version tampoco deberían exportarse).

~ Los problemas de Postcondition of backend was violated: drop key system:/elektra/modules/cache/infos/licence not belonging to "system:/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint solo ocurren en # 3447 y solo para el complemento cache . Entonces todavía hay un error en # 3447. Sin embargo, solucionar este problema kdb export también eliminaría el problema. ~

CORRECCIÓN: Los problemas posteriores a la condición también ocurren en el contenedor de la ventana acoplable.

En el contenedor de arriba, ejecuté (directamente después de las otras cosas):

ctest -R kdb_global_umount --output-on-failure

Después de eso, cualquier comando kdb que intente acceder al KDB informa de un montón de postcondition advertencias, por ejemplo, kdb ls system .

Además, si intento ejecutar kdb rm -r system , obtengo:

Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version (value Below are version information of the Elektra Library you are currently using) tried to be removed

Que kdb rm -r system falle sea a propósito. ¿Que esperabas?

Sin embargo, debo admitir que el mensaje de error es bastante malo (incluso gramatical y semánticamente: el usuario intentó algo, no la clave).

¿Que esperabas?

Para ser justos, sí kdb rm -r system no tiene mucho sentido en un sistema real. En una configuración de desarrollo, podría ser útil (pero eliminar los archivos manualmente tampoco es difícil).

Sin embargo, debo admitir que el mensaje de error es bastante malo.

Creo que esto es lo que más me confundió. Si el mensaje decía algo como "eliminar ... no permitido", habría entendido que hice algo mal. Además AFAIK definimos Interface Errors como un error en el código y no como algo causado por el usuario.

En cuanto al complemento version y los complementos de solo lectura en general: creo que debería haber una forma de ignorar estos errores de los complementos de solo lectura al llamar a kdb rm (tal vez kdb rm -rf ).
En cierto nivel, "eliminar" las claves de solo lectura tiene sentido, al menos cuando eliminamos todo lo que está debajo del punto de montaje de solo lectura a la vez. kdb rm -r some/mountpoint debería eliminar todo el archivo de configuración subyacente para some/mountpoint , es decir, la condición posterior es que no hay ningún archivo de configuración. Dado que los complementos de solo lectura (al menos aquellos que funcionan como version ) no tienen archivos de configuración, la condición posterior se satisface automáticamente.

En una configuración de desarrollo, podría ser útil

Para el desarrollo hay kdb reset .

Si el mensaje decía algo como "eliminando ... no permitido"

¡Estoy de acuerdo completamente! ¿Y el # 3498?

tal vez kdb rm -rf

Encuentro -f confuso, ya que no puede forzarlo, solo ignorarlo, por lo que --without-elektra ¿sería más adecuado en mi humilde opinión?

debería eliminar todo el archivo de configuración subyacente para

Sí, este es el caso y el resolutor se encarga de ello.

la condición posterior se satisface automáticamente.

Naja, también existe la condición posterior de que después de kdb rm key kdb get key devuelve una clave no encontrada. Esta condición posterior no se cumpliría.

Cambiar el mensaje de error debería ser suficiente

¿Hay errores restantes descritos en este número?

AFAIK, este y el siguiente comentario (es decir, el problema original) aún están sin resolver: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Lo siento, parece que entendí mal este problema al principio. Permítanme recapitular para ver si lo entiendo correctamente ahora.

Desde la perspectiva del caché, queremos reutilizar los archivos mmap tanto como sea posible. Por lo tanto, si alguien llama a kdbGet en "system/this" y el punto de montaje es en realidad "system" , persistiremos "system" completamente. Cuando alguien llama kdbGet en "system/other" , la caché ya está presente, lo que acelera bastante las cosas. Básicamente creamos un archivo de caché mmap por punto de montaje, pero almacenamos TODAS las claves debajo del punto de montaje.

Si ahora entiendo el problema correctamente, su punto es que el almacenamiento en caché de "system/elektra/modules" y similares es ambos:

1. erróneo y
2. irrelevante, ya que la obtención de estas claves es rápida de todos modos.

EDITAR: Actualmente, obtener el caché evita por completo ksAppend y otras operaciones. Así preservamos el OPMPHM y todo. Si comenzamos ksAppend-ing "system/elektra/modules" al resto del punto de montaje del sistema, ciertamente perderemos algo de rendimiento. Tal vez no sea relevante para el espacio de nombres del sistema, pero ciertamente afectaría el rendimiento si tuviéramos casos extremos como este en todas partes.

Nota: Marqué los comentarios con respecto a las cosas kdb rm system como resueltos, por lo que están ocultos por Github. Eso debería aclarar un poco este problema.

Si ahora entiendo el problema correctamente, su punto es que el almacenamiento en caché de "system/elektra/modules" y similares son ambos:

1. erróneo y
2. irrelevante, ya que la obtención de estas claves es rápida de todos modos.

Solo almacenarlos en caché es erróneo, sí, pero aún podríamos almacenarlos en caché, siempre que haya algo de lógica para detectar que las claves cambiaron. No puedo comentar sobre la velocidad, pero el uso de la caché podría ser aún más rápido. Como dijiste, evita ksAppend y también evita muchas llamadas a complementos.

El problema original es solo sobre el comportamiento de kdb export . Su salida nunca debe contener claves por debajo de system/elektra/modules o system/elektra/version , ya que son específicas de la instalación de Elektra y no deben importarse a otro KDB.

No investigué de dónde provienen esas claves, por lo que no estoy seguro de que el complemento cache esté realmente involucrado aquí. La mejor solución podría ser siempre ksCut estas partes en kdb export . De esa forma, el problema no puede reaparecer si algo cambia.

También está el problema "Se violó la condición posterior del backend". Hasta ahora tengo entendido que este problema es causado por kdb export producen claves en system/elektra/modules , pero estoy 100% seguro:

Si sigue los pasos en https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 y luego ejecute

ctest -R kdb_global_umount --output-on-failure

bin/kdb ls system

(como dije en el siguiente comentario), obtendrás muchos:

Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint

En realidad, esta es la única referencia al complemento cache . AFAICT esto es lo que sucede aquí:

• El procedimiento de "Copia de seguridad y restauración" de la prueba utiliza kdb export y kdb import .
• De alguna manera, esto da como resultado que las claves de system/elektra/modules/cache se escriban de forma persistente en el archivo elektra.ecf .
• Cuando llamamos a cualquier forma de kdbGet través de, por ejemplo, kdb ls system , tenemos el problema.
• No estoy seguro de cuál es exactamente este problema, pero estoy bastante seguro de que una clave system/elektra/modules/... nunca debería escribirse en el disco.
• La única forma de recuperarse es _manualmente_ eliminar las claves system/elektra/modules/... de elektra.ecf .

Posiblemente esto tenga que arreglarse en kdb import no en el caché.

¡Muchas gracias por informar de esto!

La caché definitivamente almacena estas (cualquiera) claves si están presentes en el conjunto de claves devuelto desde kdbGet . No hay excepciones para la caché. Sin embargo, como dijiste, no tiene sentido permitir estas claves en kdb import . Veré si puedo reproducir esto de su descripción y solucionarlo.

Si el problema ocurre solo al usar kdb import , simplemente soltaría estas claves especiales en la importación.

Estoy de acuerdo con @mpranj en que el caché debería devolver todo por completo.

Su salida nunca debe contener claves debajo de system / elektra / modules o system / elektra / version ya que son específicas de la instalación de Elektra y no deben importarse a otro KDB.

La exportación no es solo para importar, sino también para mostrar múltiples claves / valores para un usuario. No hay nada de malo en kdb export system/elektra/version/constants simpleini para ver toda la información de la versión.

No investigué de dónde provienen esas claves, por lo que no estoy seguro de que el complemento de caché esté realmente involucrado aquí. La mejor solución podría ser ksCut siempre estas partes en kdb export. De esa forma, el problema no puede reaparecer si algo cambia.

Tal ksCut ocurre cuando dices --without-elektra . Lo que podríamos hacer es cambiar el valor predeterminado: excluir elektra por defecto, excepto al importar / exportar / elektra explícitamente o decir --with-elektra .

Se violó la condición posterior del backend

Esto parece ser un error no relacionado. (Tal vez shellrecorder no esté usando --without-elektra ). https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469, sin embargo, parece que debería ser. (No puedo reproducir, obtengo Error response from daemon: pull access denied for elektra-fedora-32, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. )

No puedo reproducir

No hemos publicado esta imagen en Docker Hub.

La condición previa aquí es que compile la imagen de la ventana acoplable a partir de scripts/docker/fedora/32/Dockerfile y etiquete la compilación con -t elektra-fedora-32:latest cuando ejecute docker build .

Algo como:

cd scripts/docker/fedora/32/
docker build -t elektra-fedora-32:latest -f ./Dockerfile .

Gracias, sí, puedo reproducir los problemas Postcondition of backend was violated ahora en el maestro (como lo describe @kodebach en la imagen de la

 Sorry, 17 warnings were issued ;(
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/close not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/get not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/open not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/set not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/author not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/description not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/metadata not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/needs not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/placements not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/provides not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/recommends not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/status not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/version not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint

El problema claramente no está relacionado con kdb export ya que también ocurre, por ejemplo, con kdb ls o kdb cache clear .

Curiosamente, kdb cache clear no ayuda, pero aún podría ser un problema de la caché (ya que las herramientas kdb primero usan KDB para obtener su configuración).

@mpranj ¿tienes una idea?

Lo que podríamos hacer es cambiar el valor predeterminado: excluir elektra por defecto, excepto al importar / exportar / elektra explícitamente o decir --with-elektra.

Sí, definitivamente sería una mejor solución. Idealmente, también diferenciaríamos entre system/elektra/modules / system/elektra/version y el resto de system/elektra . La configuración del punto de montaje y la configuración global del complemento son mucho más útiles que los módulos y las claves de versión (que se generan en tiempo de ejecución).

El problema claramente no está relacionado con kdb export ya que también ocurre, por ejemplo, con kdb ls o kdb cache clear .

Como dije, lo de "Postcondición" es probablemente un error en kdb import .

Curiosamente kdb cache clear no ayuda

¿Por qué lo haría? Como dije, el problema es que las claves system/elektra/modules se almacenan en elektra.ecf . Si siguió mis pasos anteriores (específicamente utilizó las mismas opciones cmake ), puede verlo ejecutando

cat config/system/elektra.ecf

dentro del directorio build .

Como dije, lo de "Postcondición" es probablemente un error en la importación de kdb.

Como kdb import no hace mucho más que crear un KeySet y llamar a kdbSet , me temo que el problema está en algún lugar de kdbSet . El comportamiento correcto de almacenar cualquier cosa en system/elektra/modules debe ser un error o descarte, y definitivamente no persistir. Pero obviamente este no es el comportamiento:

kdb set system/elektra/modules/NOTALLOWED
kdb ls system/elektra/modules
#> system/elektra/modules/NOTALLOWED
#> system/elektra/modules/cache
...

Entonces, cuando se monta un complemento NOTALLOWED, tenemos el problema como se describe aquí. Por lo tanto, necesitamos que kdbSet falle en cualquier intento de escribir en system/elektra/modules .

En realidad, necesitamos definir la semántica de toda la jerarquía /elektra , que probablemente sea una tarea más grande ...

el problema es que las claves del sistema / elektra / módulos se almacenan en elektra.ecf

Lo siento, no lo vi cuando estaba saltando entre los comentarios tratando de reproducirlo.