GNOME Bugzilla – Bug 708258
[PATCH] dconf update is not correctly checking the mtime of the keyfiles
Last modified: 2018-09-21 16:13:21 UTC
Created attachment 255130 [details] [review] dconf-fix-mtime-directory.patch 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 https://wiki.gnome.org/dconf/SystemAdministrators: > 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"
hi, 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.
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).
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.
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... :/
*** Bug 741437 has been marked as a duplicate of this bug. ***
(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.
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".
Created attachment 372989 [details] [review] Another version of the fix Hi, 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" :) ). Regards Marek
-- 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: https://gitlab.gnome.org/GNOME/dconf/issues/11.