| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On failure to open a gvdb file in /etc/dconf/db we would issue a warning
once per process -- even if multiple files were missing.
This was enforced using a static variable.
An unfortunate side effect of this global state is that the testcases
couldn't reliably know if to expect the error or not. This issue was
side-stepped by running any cases that may emit the warning under a
fork, but that made it difficult to debug some of the cases.
Rework the backends not to use global state for the flag and instead
store it per-source.
Remove a use of g_test_trap_fork().
|
| |
|
|
|
|
|
|
|
| |
Don't use the access() system call from the service source because this
bypasses the mocking layer in the testsuite. Use gvdb_table_new()
instead. This also avoids an extra syscall.
Also: change a couple of criticals to warnings because they are not
programmer errors.
|
| |
|
|
| |
We ought to be including this from each .c file.
|
| |
|
|
|
| |
Instead of calling Init() blindly on startup for any service-db, only do
it if the file is missing when we go to open it.
|
|
|
service-db databases are based on a gvdb in the user runtime dir
maintained by the dconf-service.
On startup, the client will send an Init message to the service to
ensure that the database is properly initialised. After that, things
are pretty much the same except that the values are read from the file
in the runtime dir instead of from the home directory.
We also drop the "shm" signalling mechanism for this case and instead
use the same invalidation trick that system databases use (ie:
overwriting the old gvdb header after writing the new file).
|
