(In reply to comment #0)
> Using tracker 0.16.1 on Fedora 19
> After logging in (starting gnome-session which starts tracker-miner-fs without
> parameters), tracker-miner-fs changes (writes) the following dconf keys:
> 
> /org/freedesktop/tracker/miner/files/verbosity "errors"
> /org/freedesktop/tracker/miner/files/sched-idle "never"
> /org/freedesktop/tracker/miner/files/ignored-directories-with-content
> ['backup.metadata']
> /org/freedesktop/tracker/miner/files/ignored-directories ['core-dumps', 'CVS',
> 'lost+found', 'po']
> /org/freedesktop/tracker/miner/files/ignored-files ['*~', 'autom4te', '*.aux',
> 'confdefs.h', 'config.status', 'configure', 'confstat', 'conftest', '*.csproj',
> '*.gmo', '*.in', '*.la', 'libtool', '*.lo', '*.loT', 'ltmain.sh', '*.lzo',
> '*.m4', 'Makefile', '*.nvram', '*.o', '*.omf', '*.orig', '*.part', '*.pc',
> '*.po', '*.rcore', '*.rej', 'SCCS', '*.tmp', '*.vm*', '*.vmdk']
> /org/freedesktop/tracker/miner/files/index-single-directories ['$HOME']
> /org/freedesktop/tracker/miner/files/index-recursive-directories ['&DESKTOP',
> '&PICTURES', '&DOCUMENTS', '&DOWNLOAD', '&MUSIC', '&VIDEOS']
> /org/freedesktop/tracker/miner/files/index-on-battery-first-time false
> /org/freedesktop/tracker/miner/files/initial-sleep 15
> /org/freedesktop/tracker/miner/files/sched-idle "never"
> /org/freedesktop/tracker/miner/files/verbosity "errors"

Hi Christian, was this the first time you had run Tracker or logged into your machine since installing or upgrading to F19?

This looks like it is setting the defaults.
 
> This is bad for 2 reasons:
> 1. tracker should respect those settings in dconf - otherwise there would be no
> reason to use dconf. Where is tracker using those settings from anyway? In fact
> they are what I set them and thus differ from the defaults.

We shouldn't be writing any config on start up. In fact, the miner-fs shouldn't *EVER* write config unless it doesn't exist.

This may be a throwback from when we had to write a .cfg file (and still do if people prefer to use those over dconf).

Can you confirm this happens every time you log in?

Also, are the settings remaining in dconf after miner-fs has stopped running? That could explain why we might persist in trying to do this.

> 2. according to https://wiki.gnome.org/dconf writes to dconf are "less
> optimized" so they might have noticeable impact on system performance.

What do you mean by writes to dconf? We use GSettings via GLib, so we do use dconf (in a way), do you mean a specific way other than GSettings here?
 
> How to check that: add DCONF_BLAME to env (e.g. by adding to kernel boot
> parameter) and run 'dconf blame' after logging in

I don't have a version of dconf here with blame sadly. Are you able to provide more details for us to understand this better please?

Thanks :)

Hi Martyn
This was not the first time I started Fedora 19 or Gnome 3.8 or tracker or anything else. It was not after updating even just a minor release (e.g. 3.8.2 to 3.8.3). I didn't have "GNOME Initial Setup Copy Worker" enabled.

According to dconf-editor (from schema.xml files) those settings are not the defaults. At least sched-idle was manually set to "never" and index-on-battery-first-time was set to false. Both were settings I manually configured before testing tracker with dconf blame using the tracker GUI. Seems more to me like tracker reads the settings from dconf and writes them back.


>Can you confirm this happens every time you log in?

I can confirm this happens every time I log in.


>What do you mean by writes to dconf? We use GSettings via GLib,
>so we do use dconf (in a way), do you mean a specific way other
>than GSettings here?

No, I just mean the case you described: using GSettings which uses dconf as backend.


>I don't have a version of dconf here with blame sadly.

AFAIK every dconf provides the blame option. Ryan Lortie (maintainer of dconf) told me this:

>>Start your computer with "DCONF_BLAME=1" on the kernel commandline
>>or figure out a way to get it into the environment of your session.
>>
>>Once logged in, you should then be able to type "dconf blame" at
>>the commandline to get a list of all of the things that have been
>>written to dconf since startup.

>Are you able to provide more details for us to understand this
>better please?
I tried a bit using tracker-preferences (the GUI tracker settings tool) and found out that every single preference is consistent over logout/login, so tracker really seems to just read settings and overwrite them again.

I looked into the source code and found it quite strange that tracker/miner/fs/tracker-config.c provides setters for those variables. Isn't tracker-miner-fs supposed to index the file system? Instead tracker-main.c calls

	if (verbosity > -1) {
		tracker_config_set_verbosity (config, verbosity);
	}

	if (initial_sleep > -1) {
		tracker_config_set_initial_sleep (config, initial_sleep);
	}

in ANY case and AFTER those values got read from DConf. Seems like there is something very wrong…

(In reply to comment #2)
> >I don't have a version of dconf here with blame sadly.
> 
> AFAIK every dconf provides the blame option. Ryan Lortie (maintainer of dconf)
> told me this:

Interesting...

So "dconf blame" gives:

  $ dconf blame
  error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `ca.desrt.dconf.ServiceInfo' on object at path /ca/desrt/dconf

  Unknown command 'blame'

  ...

If you don't have the DCONF_BLAME=1 in the kernel command line.

> I looked into the source code and found it quite strange that
> tracker/miner/fs/tracker-config.c provides setters for those variables. Isn't
> tracker-miner-fs supposed to index the file system? Instead tracker-main.c
> calls
> 
>     if (verbosity > -1) {
>         tracker_config_set_verbosity (config, verbosity);
>     }
> 
>     if (initial_sleep > -1) {
>         tracker_config_set_initial_sleep (config, initial_sleep);
>     }
> 
> in ANY case and AFTER those values got read from DConf. Seems like there is
> something very wrong…

The command line can override the saved config we load at run time, these should not be saved back to dconf, but rather used in memory for the duration the miner-fs runs. If this is causing the saving of the config, that's a bug indeed.

I have a suspicion that a change I put in place to fix another bug has caused this to start writing the config. Before we used g_settings_apply() and g_settings_delay(), but I disabled those:

  commit 76be950745ff548fa3b15fd6facce79516120db9
  Author: Martyn Russell <martyn@lanedo.com>
  Date:   Thu Mar 7 21:16:59 2013 +0000

      tracker-miner-fs: Fixes not listening for config changes and acting on them
    
      https://bugzilla.gnome.org/show_bug.cgi?id=693198

Now that I research a bit deeper into the code, it looks like this change is part of the problem. Before, we would only apply changes when tracker_config_save() was called (which it never is actually, it used to be). Clearly setting the config from the command line on start is part of the problem.

The idea of the config here is to have 4 functions:

1. To update in real time from dconf/tracker-preferences.
2. To be used internally by miner-fs for all settings.
3. To be overridden by the command line.
4. To save the config to ~/.config/tracker/tracker-miner-fs.cfg when the TRACKER_USE_CONFIG_FILES env is defined.

In fixing #1, I broke #3 it seems. I need some time to come up with a patch here. It's likely the fix is easiest done by using G_SETTINGS_BIND_GET instead of G_SETTINGS_BIND_DEFAULT and remove the _save() function. I need to check that doesn't break case #4 above, some people still prefer .cfg files to dconf.

Why should a fix for tracker-preferences change tracker-miner-fs? Why should tracker-miner-fs be able to write settings at all?

(In reply to comment #4)
> Why should a fix for tracker-preferences change tracker-miner-fs? 

The fix was to make sure miner-fs reacts to indexed location changes in the config. It worked before but after moving to GSettings, it was broken and required a restart. So I fixed it.

> Why should tracker-miner-fs be able to write settings at all?

Because if you use a .cfg file (which is like an INI file), there is no magical daemon (like dconf) to write those configs for you automatically. The only other binary that does this is tracker-preferences. So in the even people use tracker _WITHOUT_ dconf on their system (which happens), they can use TRACKER_USE_CONFIG_FILES. This requires us to save a .cfg file on first start when there is none that exists. Otherwise, how do people change that config. IT should be noted, tracker-preferences is another binary that is an optional build-time configuration, so you don't always have that available to play with settings.

It should be added, I think the TRACKER_USE_CONFIG_FILES case is broken at the moment too, because we don't call tracker_config_save() at any point.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

IF you still see this after my fix, let me know.

commit 169426d2854278dad4650a1658f579cc17398173
Author: Martyn Russell <martyn@lanedo.com>
Date:   Thu Jul 25 13:25:55 2013 +0100

    libtracker-common, tracker-miner-fs: Fixed config file and settings overwriting
    
    libtracker-common: Added config tracing to avoid spaming logs most of the
    time, but kept for cases where we need to see what we're doing with configs.
    
    libtracker-common: Added +tracker_config_file_import_to_settings() We call
    this now from tracker-config.c in miner-fs when using config files to update
    our local GSettings. No overwriting stored GSettings happens.
    
    tracker-miner-fs: Removed all unused _set() functions in tracker-config.[ch].
    
    tracker-miner-fs: Only allow *local* GSettings override of verbosity and
    initial-sleep from the command line.
    
    tracker-miner-fs: Don't re-write the default config in some cases.
    
    tracker-miner-fs: For config, don't bind DEFAULT, but only GET for most
    properties, we don't want to save back what we change locally, that's what
    tracker-preferences does.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=703759

*** Bug 701468 has been marked as a duplicate of this bug. ***