The problem described below appears sometimes when a folder is opened from context menu with an option similar to "Open with" - "Other application"

enter image description here

What happens is that the program selected in this way (and which after that is already available under "Open with" context menu for selected folder) takes over the file manager function in different other applications, like Firefox, Chromium, uGet, Calibre, etc, which have options similar to 'Open containing folder'.

enter image description here

enter image description here

enter image description here

Not all programs selected in this way trigger the problem (from what I've seen, namely qmmp, Decibel audio player, Easytag, Atom text editor are some of those). - Also, not all applications mentioned as affected by the problem (Firefox, etc) are to be affected at the same time. In the past I have often seen this in Firefox, but last time Firefox was not affected but uGet and Calibre were.)

This problem is frequently reported on Linux sites like this, for example:

"Open Containing Folder" not using the file manager

Set standard file browser for "open containing folder"

Stop folders opening with different application than the file manager

“Open containing folder” in Firefox does not use my default file manager

What happens is that the program in question becomes the first to appear in /usr/share/applications/mimeinfo.cache after inode/directory=.

This doesn't cause automatically the problem reported in the linked questions, I have a system (elementaryOS Loki) where the file manager is listed there last without any problems, but in another Linux (Manjaro) the file manager has to be listed first, like (for Nemo) inode/directory=nemo.desktop;decibel-audio-player.desktop;au‌​dacious.desktop;.

But how to open a folder in a such program without this kind of conflicts with the file manager?

I'm creating this question in order to provide the answer.


As indicated in a comment by don_crissti under my initial answer: if the problem is triggered automatically after installing a certain program (in my case Decibel), it will re-appear even after correcting the file /usr/share/applications/mimeinfo.cache when a new installation or an update by the command update-desktop-database. (I will add te suggested solution to the answer too.)


The idea is to already have the needed programs in the 'Open with' context-menu for a selected folder without the need to select "Other application".

Editing the line inode/directory= in /usr/share/applications/mimeinfo.cache is not useful because, as indicated in a comment by don_crissti, the problem re-appears after an update or a program install because of the command update-desktop-database.

In fact only some programs will take over the file manager role as indicated by the question, but those that do will in some cases take over directly, simply after their installation, and will do again after update-desktop-database.

As suggested here by the aforementioned user, you need to edit ~/.local/share/applications/mimeapps.list like:

[Default Applications]

In another system (Cinnamon Manjaro, where there is no mimeapps.list in usr/share/applications, only mimeinfo.cache and seems non-freedesktop-complient) the file to use is ~/.local/share/applications/mimeinfo.cache with a content like

[MIME Cache]

It is essential to put the file manager first and then the programs to add to the 'open with' context menu.

For example, the above will give

enter image description here

  • 1
    Editing that system file doesn't "avoid" the problem which occurs after installing certain applications because, as I've explained here, the issue is a result of running update-desktop-database post-install (all package managers do that). The only way to avoid it is to maintain your own mimeapps.list under ~/.local/... – don_crissti Jan 12 '17 at 21:51
  • @don_crissti - indeed, if a program has triggered that problem in the first place automatically, the command update-desktop-database (which is run also upon updates) will bring it back unless a new file is created in ~/.local/share/applications as you suggest. Only that in some cases (like in my Manjaro), where there is no mimeapps.list in usr/share/applications, creating one in ~/.local/share/applications as you indicate will not fix it, but a ~/.local/share/applications/mimeinfo.cache will do the trick. – user32012 Jan 13 '17 at 10:25
  • 1
    I have already answered and explained what & why, the link is in my 1st comment above. If you just want to duplicate the info then feel free to do so... I don't understand your question... As I said, you cannot avoid this unless you maintain your own mimeapps.list/mimeinfo.cache (and even then... I'm not familiar with all DEs on this planet). And btw, this has nothing to do with your distro, it's DE-related. – don_crissti Jan 13 '17 at 10:47
  • @don_crissti - Your comment was very useful, I was about to delete my first comments. Please see my updated answer. – user32012 Jan 13 '17 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy