#887 libfm and XDG_CONFIG_DIRS

libfm (303)

It seems libfm does not respect configuration files at directories listed in XDG_CONFIG_DIRS (see XDG Base Directory Specification). If I copy a configuration file from my XDG_CONFIG_HOME to a directory listed there and change an option, it is not used by libfm. An easy way to test it is to copy 'libfm.conf', change the value of 'single_click' in that file and restart libfm.


  • Lonely Stranger

    Lonely Stranger - 2014-08-08

    In fact, it does respect XDG_CONFIG_DIRS completely as it's stated in mentioned specification, and any setting in $XDG_CONFIG_HOME/libfm/libfm.conf has a priority and overrides setting from any system config, in accordance with the specification. There are few exceptions though - terminal, archiver and list_view_size_units are always ignored in system configs if user config is present, that was done deliberatedly to allow user unset them.
    So I believe if you copy your config into some system path then stop pcmanfm, remove ~/.config/libfm/libfm.conf, then start pcmanfm, you'll get all your values from that system config. Thanks.

  • Lonely Stranger

    Lonely Stranger - 2014-08-08
    • status: open --> closed-invalid
    • assigned_to: Lonely Stranger
  • Maurício

    Maurício - 2014-08-08

    If I understand you correctly, you thought I forgot to delete the configuration file at $XDG_CONFIG_HOME/libfm before filling this report. I did not. Just test what you suggested and you'll see it doesn't work.

  • Lonely Stranger

    Lonely Stranger - 2014-08-08

    Have you deleted that file exactly after killing all instances of PCManFM? As I said you already you should do it in exactly that order because that file is always overwritten again when PCManFM exits and therefore is read on its restart ignoring all the system-wide statements.

    And also take into consideration that PCManFM may be instantly restarted by lxsession so you should ensure there is no PCManFM running at the time you delete that file to get what you want.

    Last edit: Lonely Stranger 2014-08-08
  • Maurício

    Maurício - 2014-08-09

    An easy way to test is this:

    mkdir bla
    export XDG_CONFIG_HOME=~/bla

    New config files are created inside ~/bla, and they do not mimic the configuration in the first directory listed in XDG_CONFIG_DIRS. I insist that you write a test yourself before replying. Create a new directory, list it first in XDG_CONFIG_DIRS, copy your configuration there, change it, take all the precautions you think you need. You'll see the problem.

  • Lonely Stranger

    Lonely Stranger - 2014-08-09

    Yes, it works exactly as it should - every single setting is picked from path in $XDG_CONFIG_DIRS when config from $XDG_CONFIG_HOME is missing. No problem is here as well as there are no problems for whole lot of users which are getting their defaults from distro's system default config at their first run. Check what you are doing wrong, please.

  • Maurício

    Maurício - 2014-08-10

    I was able to isolate the problem: if I change XDG_CONFIG_DIRS from pattern




    everything works fine. So, it seems libfm does not miss directories from XDG_CONFIG_DIRS, it just reads them in the wrong order.

    I thought that could be the problem after reading these lines from file fm-config.c:

    dirs = g_get_system_config_dirs();
        path = g_build_filename(*dir, name, NULL);
        if(g_key_file_load_from_file(kf, path, 0, NULL))
            fm_config_load_from_key_file(cfg, kf);

    It seems libfm gets the list of directories and transverse it, overwriting what is read first by what is read later. According to the specification, the list of directories is preference ordered. I believe this could be corrected just by reversing the transverse order. (I didn't go deep into the code to check that, though.)

  • Lonely Stranger

    Lonely Stranger - 2014-08-10

    Ah, so then it is a completely different issue, not one you reported. It's fixed in the GIT repository now. Thank you very much. :)

  • Lonely Stranger

    Lonely Stranger - 2014-08-10
    • labels: --> libfm
    • status: closed-invalid --> closed-fixed
  • Maurício

    Maurício - 2014-08-10

    Great. Thanks for the fast fix.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks