The trash is in the pointer dereference in gvdb_table_is_valid in gvdb/gvdb-reader.c.
Since the database file is zero-length, I assume that something hasn't noticed and we get SEGV.
When the files are gone, we get an assertion failure.
These are both bad failure modes, but not critical bugs. What is clear then is that it is mandatory that /etc/dconf/db/foo exist whenever you have system-db:foo, and it must exist as a real gvdb database. That's annoying, because we only want to use the foo.d directory to hold a textual key specification. However, it's something we can work around, I think.
So please leave this open as a bug that the program should not crash when the database files are incorrect, but (assuming my understanding above is correct) there is no urgency for us.
Now we have a different problem, however. There is no way I can see to create a proper empty gvdb database. The dconf program doesn't do it, and dconf-settings certainly doesn't.
The trash is in the pointer dereference in gvdb_table_is_valid in gvdb/gvdb-reader.c.
Since the database file is zero-length, I assume that something hasn't noticed and we get SEGV.
When the files are gone, we get an assertion failure.
These are both bad failure modes, but not critical bugs. What is clear then is that it is mandatory that /etc/dconf/db/foo exist whenever you have system-db:foo, and it must exist as a real gvdb database. That's annoying, because we only want to use the foo.d directory to hold a textual key specification. However, it's something we can work around, I think.
So please leave this open as a bug that the program should not crash when the database files are incorrect, but (assuming my understanding above is correct) there is no urgency for us.
Now we have a different problem, however. There is no way I can see to create a proper empty gvdb database. The dconf program doesn't do it, and dconf-settings certainly doesn't.
This is a rather serious gap.