After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708258 - [PATCH] dconf update is not correctly checking the mtime of the keyfiles
[PATCH] dconf update is not correctly checking the mtime of the keyfiles
Product: dconf
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: dconf-maint
: 741437 (view as bug list)
Depends on:
Reported: 2013-09-17 18:10 UTC by Carlos Alberto Lopez Perez
Modified: 2018-09-21 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

dconf-fix-mtime-directory.patch (2.07 KB, patch)
2013-09-17 18:10 UTC, Carlos Alberto Lopez Perez
none Details | Review
Another version of the fix (2.53 KB, patch)
2018-07-10 16:42 UTC, Marek Kašík
none Details | Review

Description Carlos Alberto Lopez Perez 2013-09-17 18:10:28 UTC
Created attachment 255130 [details] [review]

dconf currently compares the mtime of the directory that contains the keyfiles (for example "/etc/dconf/db/local.d") with the mtime of the database to decide if it has to trigger an update.

Quoting from

> After modifying any keyfile in one of these directories, the 'dconf update' tool should be run. This tool scans the /etc/dconf/db/ directory for databases with corresponding '.d' directories. If the timestamp on the directory is newer than the one on the file, the file is regenerated. The tool sends a notification on the system D-Bus to all running applications instructing them to re-read their settings. 

This check alone is wrong, because the mtime of a directory only changes when a file is added, removed or renamed. But not when the contents of the file are modified within the directory itself.

To reproduce this buggy behaviour, edit any keyfile with the nano editor, or append to it with the shell, and check how the mtime of the directory don't changes.

$ md5sum testdir/somefile
d8e8fca2dc0f896fd7cb4cb0031ba249  testdir/somefile
$ stat testdir/|grep Modify
Modify: 2013-09-17 20:04:11.226476625 +0200
$ echo "something" >> testdir/somefile
$ md5sum testdir/somefile
1e3ead11c29e7ce8ad2a60c7968ee0cf  testdir/somefile
$ stat testdir/|grep Modify
Modify: 2013-09-17 20:04:11.226476625 +0200

This patch adds an extra check that compares also the mtime of the files inside the directories "$dirname" and "$dirname/locks"
Comment 1 Allison Karlitskaya (desrt) 2013-09-17 18:40:41 UTC

This issue has been reported before, and I think it's NOTABUG because it's not possible to safely modify a file without indirectly modifying the timestamp of the directory.

All good editors replace files in a directory by writing to a new temporary file, calling fsync() and then renaming that over the original.  This always involves updating the mtime of the directory.  Anything else is unsafe.

It's a common convention for tools that update caches to operate in this way, and I think it's appropriate for dconf-update to do so as well.
Comment 2 Allison Karlitskaya (desrt) 2013-09-17 18:41:22 UTC
Just out of curiosity -- did you observe this 'in the wild' with a particular editor?  I've heard reports that sudo's editor command is broken in this respect (but that was already filed upstream with them).
Comment 3 Carlos Alberto Lopez Perez 2013-09-17 20:40:55 UTC
Yes. I observed this on the wild.

I was editing the configuration of the key files with the editor GNU nano and this bug drove me crazy for a few hours until I realized that dconf was skipping to update the DB because it was checking the mtime of the directory instead of the mtime of the key file itself.
Comment 4 Allison Karlitskaya (desrt) 2013-11-28 14:47:34 UTC
You should probably report a bug against nano for not safely replacing the files that you use it to edit.

Meanwhile, I think I may fix this bug.  Too many people using bad editors... :/
Comment 5 David King 2014-12-12 17:08:21 UTC
*** Bug 741437 has been marked as a duplicate of this bug. ***
Comment 6 Murray Cumming 2015-01-28 20:53:20 UTC
(In reply to comment #4)
> Meanwhile, I think I may fix this bug.  Too many people using bad editors... :/

Bug #741437 shows the same problem if you just add a file, such as a lock file, not just when you edit a file.
Comment 7 Carlos Alberto Lopez Perez 2016-11-22 01:57:57 UTC
I think putting the blame on bad editors doesn't help anyone.

The files can be updated by multiple means that don't involve an editor, like copying new config files over the current ones. In such case the mtime of the directory is also not updated.

I really think dconf is not doing the right thing here: checking if there are new changes by only checking the directory mtime is insufficient, as it has been already proved above and in bug 741437.

And it amuses me that a simple fix as the one I proposed has been ignored for 3 years already because of "bad editors -- not my problem".
Comment 8 Marek Kašík 2018-07-10 16:42:01 UTC
Created attachment 372989 [details] [review]
Another version of the fix


I've got another downstream bug report for this issue. The problem is caused by an automatic deployment tool which just redirects concatenated key files and does not change mtimes of the upper directories. I've prepared simple patch which fixes the issue for me and I would like to ask you to consider it for including in upstream. (and I'm sorry, I've just realized that a patch is already attached here... so you can take this just as a "ping" :) ).


Comment 9 GNOME Infrastructure Team 2018-09-21 16:13:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: