gvdb does not treat corrupt files as empty as promised; dconf suffers

gvdb_table_new is used by dconf when writing settings to open/map the settings database before modifying values in memory, writing a new database and moving it over atomically.

It is documented that any invalid file is equivalent to an empty file: https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gvdb/gvdb-reader.c#L196

However, this is not implemented. An error is propagated in the event that the header doesn't contain the right magic: https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gvdb/gvdb-reader.c#L162

If gvdb were to behave as documented, this would not happen - dconf would create a new file and then move it over the invalid one, which seems desirable.

However, dconf itself is documented to intentionally not want that to happen: https://gitlab.gnome.org/GNOME/dconf/blob/master/service/dconf-gvdb-utils.c#L57

But does not otherwise handle the error (move the file aside and then treat it as empty, for example).

The net consequence of this is that nothing handles the corruption - if a power interruption that leaves an invalid file written on disk, dconf can neither read nor write any settings any more, because the read error that occurs during the write path abandons the operation. This means dconf is left broken and won't ever recover itself for that user.

If you feel it's preferable to correct the documentation rather than the implementation of gvdb, I can consider a fix in dconf instead.