bug: xdg.mime.enabled = true causes crash when encountering a .json file

[MyNameIs-13]

Are you following the right branch?

• My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• I have searched the existing issues

Issue description

Intro and Workaround

Not sure if I'm supposed to add information to issue 4682 or create a new one.
Sorry in case I chose the wrong approach. (sounds like a different problem, even though the same fix/workaround can be used)

Originally posted by @hexclover in #4682 (comment)

For me setting xdg.mime.enable = false; in home-manager also works

Problem description and steps to reproduce:

encountering¹ a .json file crashes a lot of programs² in at least Gnome and KDE

I first encountered the problem on bare metal PopOS 22.04
and then reproduced it with (quickemu) VMs (Kubuntu 23.10, Ubuntu 23.10, Fedora 39)

For the tests in the VMs I used the following code (but also tested once with a multiuser install)

echo 1 >> ~/Downloads/foo.json
sudo apt install -y curl
sh <(curl -L https://nixos.org/nix/install) --no-daemon --yes
. "/home/${USER}/.nix-profile/etc/profile.d/nix.sh"
nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
nix-channel --update
nix-shell '<home-manager>' -A install

Then rebooted and tried to access/open the .json file

Maintainer CC

No response

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.6.10-76060610-generic, Pop!_OS, 22.04 LTS, nobuild`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.17.0`
 - nixpkgs: `/home/foobar/.nix-defexpr/channels/nixpkgs`

Footnotes

1. (with 'encountering' I mean clicking it in file explorer apps or opening it in editor apps) ↩

2. Explicitly tested Nautilus, gedit, new gnome Text Editor (no idea what the name is), thunar and Dolphin. ↩

[anibali]

This sounds like the same issue I ran into, so I'll add my findings in case they're helpful. From my testing I found that crashes occurred with both .json and .js files, and that the file must be non-empty for the crash to occur. Crashes still occur when the file is hidden. I also found that the issue does not exist in home-manager 23.11.

[jonknapp]

Similar to my issue, it's occurring when I try to create a zip file as well. I am running home manager + nix on PopOS.

I just started to rebuild my dotfiles from scratch to try and track down the issue. Mine crashes as soon as I introduce targets.genericLinux.enable = true; to my home manager configuration. For me, xdg.enable = false; had no effect on stopping the crashes.

[jonknapp]

Disregard my comment. While related, it's more applicable to #4682.

[0xlynett]

I'm having the same issue.

I believe it has something to do with a mismatch between the home-manager shared-mime-info version and the default version of that package (we have shared-mime-info-2.4 according to home-manager packages but the latest version for Pop is 2.1-2)

Setting xdg.mime.enabled = false fixes the issue.

Running home-manager 23.11.

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.