Firefox opening download directory with k4dirstat instead of Dolphin

[chconnor]

So... in googling this, there are dozens of threads suggesting hundreds of methods, going back almost 20 years, none of which (so far) have helped... I'm posting in case someone has a clear pointer on what to do:

If I download a file, open up the downloads, and click the folder icon to open the file with the DE file browser, Firefox no longer opens it with Dolphin but rather k4dirstat. This seems to have started recently, but I'm not totally sure of that.

My understanding is that mime handling with Firefox is somewhat of a cluster, perhaps more so with the snap thing going on now, and I can't seem to figure out how to sort this out.

I do see that in /usr/share/applications/mimeinfo.cache, for inode/directory k4dirstat is listed before dolphin, which some say is the cause, but I have no idea the proper way to remedy this (simply editing the file seems like a temporary fix at best? I added a line at the end of /usr/share/applications/defaults.list for inode/direcory to open in dolphin but that did not fix it.)

What's the latest on this issue? Anyone know?

Thanks!

[rab0171610]

While I do not use the snap firefox, I do not have this problem. My links have always opened with dolphin. The line in my file you refer to says the following:

inode/directory=org.kde.dolphin.desktop;org.kde.gwenview.desktop;org.kde.kate.desktop;

I think you can back up the file, safely remove the reference to k4dirstat, logout and log back in to see if it has any effect.

as far as your comment:

(simply editing the file seems like a temporary fix at best?

Is it though? A fix is a fix is a fix. If it solves the problem it really makes no difference. It's a quality solution if the result is the desired behavior. If it doesn't then at least you have eliminated that as a cause.

[jlittle]

A fix is a fix is a fix. If it solves the problem it really makes no difference.

I disagree. A fix that works now and some time later fails after an update overwrites it, or is in a cache that is regenerated, is not as good as a fix that sticks. Any change to files under /usr will be prone to being overwritten by an update.

Often, though, files under /usr/share can be overridden by files under ~/.local/share, so copying and editing there might be good. However, I'm not sure that will work for a cache. Looking in the Kubuntu where I'm typing this, /usr/share/applications/mimeinfo.cache is dated today, implying there is some volatility there.

[rab0171610]

A fix that works now and some time later fails after an update overwrites it, or is in a cache that is regenerated, is not as good as a fix that sticks.

I am not talking about that. I am talking about trying to edit the mime file and see what the result is. Then you monitor the situation and if you see that it is getting overwritten and the setting is not permanent, then you address that. What you do not do is do nothing and just ponder if that is a viable solution or not. You cannot say that until you try.

[rab0171610]

What we know about mimecache is that it WILL get overwritten, possibly, at some point. It is not permanent.

[rab0171610]

Try putting putting the dolphin references in defaults.list in your home directory as jlittle suggested (~.local/share/applications/).

[rab0171610]

If it is then still ignoring your defaults lists you could also try setting it manually
first check what program is default and then set it to dophin if it is not correct.
For system-wide/all users:
sudo xdg-mime query default inode/directory
sudo xdg-mime default org.kde.dolphin.desktop inode/directory

Or issue the same thing without sudo to change the settings only for yourself in your home directory.

xdg-mime query default inode/directory
xdg-mime default org.kde.dolphin.desktop inode/directory

If that still doesn't work i have no idea what is causing your problem.

[claydoh]

Some semi-useless trivia:
K4dirstat is one of those packages directly imported from Debian, and is not actually packaged by Ubuntu or the Kubuntu packaging team. You usually tell this from the package versioning lacking any references to 'ubuntu'.
(Neon doesn't package this application either, for that matter, it this means anything)
So the bug ultimately may be Debian's fault (though there are nearly zero bug reports on this app there), and Ubuntu support comes from the small, volunteer MOTU team.

Existing bug reports:
https://launchpad.net/ubuntu/+source/k4dirstat/+bugs
https://bugs.launchpad.net/ubuntu/+s...t/+bug/1970925
People should subscribe to these, who are affected by this, to 'bump' it, and give it a bit of popularity. Should only take some sort of packaging config edit, perhaps.

Now, has anyone actually looked at using System Settings to fix this error?

Also something to check may be Firefox's own native file association settings, just in case. Historically, this has been a common issue with Mozilla products not syncing with the system mime-types som times.
I am reading this:

and click the folder icon to open the file with the DE file browser, Firefox no longer opens it with Dolphin

As clicking on the download folder button inside Firefox, not KDE, and if so, looking at FF settings may be helpful
I don't think this problem has anything to do with Snap, here. Or at least it is at the bottom of the list, considering the two bugs above predate FF as a Snap. One is for 20.04. I could not reproduce this there.

[chconnor]

Thanks, all --

The system settings and xdg-mime show that dolphin is already the preferred app, e.g.
"xdg-mime query default inode/directory" yields "org.kde.dolphin.desktop", and Dolphin is at the top of the list in the system settings.

However adding the line

inode/directory=org.kde.dolphin.desktop

...to the end of ~/.local/share/applications/defaults.list did the trick -- now things open in dolphin again.

However there is some (snap?) weirdness still -- if I choose /tmp as the download location, it does save the file in /tmp, but opening the folder via the FF button opens e.g. /run/user/1000/doc/6419b1be/ with that file showing. Any thoughts on fixing that?

[rab0171610]

It looks like it is a modern way of doing things. . .
Per:
https://unix.stackexchange.com/quest...-run-user-1000

144
/run/user/$uid is created by pam_systemd and used for storing files used by running processes for that user. These might be things such as your keyring daemon, pulseaudio, etc.
Prior to systemd, these applications typically stored their files in /tmp. They couldn't use a location in /home/$user as home directories are often mounted over network filesystems, and these files should not be shared among hosts. /tmp was the only location specified by the FHS which is local, and writable by all users.
However storing all these files in /tmp is problematic as /tmp is writable by everyone, and while you can change the ownership & mode on the files being created, it's more difficult to work with.
So systemd came along and created /run/user/$uid. This directory is local to the system and only accessible by the target user. So applications looking to store their files locally no longer have to worry about access control.
It also keeps things nice and organized. When a user logs out, and no active sessions remain, pam_systemd will wipe the /run/user/$uid directory out. With various files scattered around /tmp, you couldn't do this.

[chconnor]

Ah, thanks, didn't realize this only applied to /tmp. I should have tested more.

So I use an encrypted swap, and /tmp is a tmpfs so nothing sensitive is written to disk unless RAM fills up... this /run/user/1000 directory is also a tmpfs, so in theory this arrangement doesn't compromise the security, correct? Meaning, /run/user/1000/* files are never written to disk, and if they are, it will be to the encrypted swap as before?

[rab0171610]

Meaning, /run/user/1000/* files are never written to disk, and if they are, it will be to the encrypted swap as before?

I think files in /tmp and /run are written to RAM, but only temporarily and not persistent usually. I don't think the swap file is involved, as that is used for swapping out RAM pages/memory. The security factor comes into play with run because the files are not able to be read by other users due to access controls on the directory and files within. I don't think swap is used by programs as a temporary cache or data structure for temporary files. According to that post before, /run/user/1000 is cleared upon reboot. There could still be traces on the disk however. I am not sure how much more security the average person needs, but if you are not doing anything illegal in your web browsing and not sharing your computer for the most part and are free of malware, I can't see this a problem. It is sufficient for the average user in my opinion.
Sorry I was confused and edited this to note that /tmp and /run are tmpfs which is run in RAM, so unless some nefarious person gets realtime access to the tmpfs it is unlikely to be a security risk after system is shutdown.

[rab0171610]

If someone needed even more privacy than this the better option would be to run an operating system in RAM by docache as a boot parameter with a live disk, so that the entire OS is run in RAM and nothing is persistent. That would be overkill for 99.999% of most home users and borders on paranoia in my opinion. While there are some countries that have laws and surveillance that makes this necessary, for most of the world it is not needed for just everyday web browsing and internet use. But every user has to assess that for themselves as everyone's needs are different.

[chconnor]

Thanks - I don't have a particularly high security need, but I like to take precautions that are easy enough to take. The less awkward phone calls to clients that I need to make if my computer gets stolen, the better. :-)

My understanding (which is possibly outdated and/or just wrong) is that when you make /tmp a tmpfs it becomes a RAM disk, but if you run low on RAM the contents of /tmp can theoretically written to disk when the swap gets involved. My swap is encrypted, so this is usually OK, but if this /run/user/1000 directory somehow got around that setup I'd be interested to know. Since /run/user/1000 is a tmpfs I assume it's not normally written to disk, and I further assume that if RAM gets full it could also be written to swap, and I further assume that that's fine given that my swap is encrypted. As long as my assumptions are right I'm not worried, hence the question. :-)

[rab0171610]

Yup, you got it!