Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-2879GitHub issuePublicReceived

xdg-mime and xdg-open not detecting all mime filetypes correctly

Reported by wrex · filed Sep 15, 2025Closed upstream on 2025-10-26 by ryanrhughes. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.

Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

xdg-mime and xdg-open not detecting all mime filetypes correctlyrevision 1 · captured 2026-10-04 11:35 UTC via poll

System details

Beelink Ser9 Pro, Omarchy 2.1.1

What's wrong?

Apologies in advance if this should actually be filed against something upstream. I'm still trying to get the lay of the land. I've actually managed to resolve this issue for myself, but thought I'd file this in the hope of helping others.

Problem description:

I would like text files matching the glob *.sgf to be recognized as smart game format Go boardgame records. There is a mime filetype association already correctly defined for these files in /usr/share/mime/packages/freedesktop.org.xml (that ships with Omarchy).

The correct mime filetype for .sgf files is application/x-go-sgf which is a sub-class of text/plain, but, unfortunately, the command xdg-mime query filetype <file>.sgf does NOT use the mime filetype database correctly by default.

Background:

I specifically wanted Obsidian (and other apps) to open such files in my preferred application (Sabaki). It's easy to tell the Gnome File browser to use that app by default, but as near as I can tell, that only affects the file browser application. Sadly, Obsidian or simply open <file> in a terminal would only launch nvim for sgf files.

In a terminal, open <file>.sgf (a shell function that calls xdg-open) only opens those files in nvim by default, because it's recognized as text/plain, and not as application/x-go-sgf. Same thing with pretty much any other application that can launch other programs on a file (maybe other Gnome apps follow the file browser associations?).

Solution:

xdg-mime is actually just a shell script that by default uses file -i and the "magic" database to heuristically determine filetypes by looking at the file's initial contents. Despite the xdg-mime name and intended use, by default it apparently ignores the mime filetype definitions altogether (for reasons I fail to understand).

Interestingly, however, the script looks for a program with the name mimetype if it exists and uses that instead of file to determine a file's mime filetype.

The package repository includes perl-file-mimeinfo which includes the perl scripts mimetype and mimeopen which (hallelujah!) use the mime database definitions correctly.

Unfortunately, it installs these scripts in /usr/bin/vendor_perl/bin, so xdg-mime is unlikely to find them unless that directory happens to be in a user's PATH. I simply created symlinks in /usr/bin to these scripts which completely solved my issue.

Request:

The above doesn't describe the several days of frustration (and ethanol consumption) involved in unraveling all of this. For the most part, everything in Omarchy JUST WORKED for me. Some of hardware stuff took some finagling, but this was my only real software issue.

I'd like to suggest that Omarchy distribute perl-file-mimeinfo by default, and that symlinks for mimeinfo and mimeopen get created by default.

No good deed ever goes unpunished, so I wouldn't be at all surprised if something currently depends on the currently incorrect mime detection algorithm. I've not uncovered any issues with the above solution yet, but I wouldn't call what I've done thus far a terribly robust QA.

Thanks for your consideration (and an awesome distribution!)

View raw text
### System details

Beelink Ser9 Pro, Omarchy 2.1.1

### What's wrong?

Apologies in advance if this should actually be filed against something upstream. I'm still trying to get the lay of the land. I've actually managed to resolve this issue for myself, but thought I'd file this in the hope of helping others.

## Problem description:

I would like text files matching the glob `*.sgf` to be recognized as [smart game format](https://en.wikipedia.org/wiki/Smart_Game_Format) Go boardgame records. There is a mime filetype association already correctly defined for these files in `/usr/share/mime/packages/freedesktop.org.xml` (that ships with Omarchy). 

The correct mime filetype for `.sgf` files is `application/x-go-sgf` which is a sub-class of `text/plain`, but, unfortunately, the command `xdg-mime query filetype <file>.sgf` does **NOT** use the mime filetype database correctly by default.

## Background:

I specifically wanted Obsidian (and other apps) to open such files in my preferred application (Sabaki). It's easy to tell the Gnome File browser to use that app by default, but as near as I can tell, that _only_ affects the file browser application. Sadly, Obsidian or simply `open <file>` in a terminal would only launch `nvim` for sgf files.

In a terminal, `open <file>.sgf` (a shell function that calls `xdg-open`) only opens those files in nvim by default, because it's recognized as `text/plain`, and not as `application/x-go-sgf`. Same thing with pretty much any other application that can launch other programs on a file (maybe other Gnome apps follow the file browser associations?).

## Solution:

`xdg-mime` is actually just a shell script that by default uses `file -i` and the "magic" database to heuristically determine filetypes by looking at the file's initial contents. Despite the `xdg-mime` name and intended use, by default it apparently ignores the mime filetype definitions altogether (for reasons I fail to understand).

Interestingly, however, the script looks for a program with the name `mimetype` if it exists and uses that instead of `file` to determine a file's mime filetype.

The package repository includes `perl-file-mimeinfo` which includes the perl scripts `mimetype` and `mimeopen` which (hallelujah!) use the mime database definitions correctly.

Unfortunately, it installs these scripts in `/usr/bin/vendor_perl/bin`, so `xdg-mime` is unlikely to find them unless that directory happens to be in a user's PATH. I simply created symlinks in `/usr/bin` to these scripts which completely solved my issue.

## Request:

The above doesn't describe the several days of frustration (and ethanol consumption) involved in unraveling all of this. For the most part, everything in Omarchy JUST WORKED for me. Some of hardware stuff took some finagling, but this was my only real software issue.

I'd like to suggest that Omarchy distribute `perl-file-mimeinfo` by default, and that symlinks for `mimeinfo` and `mimeopen` get created by default.

No good deed ever goes unpunished, so I wouldn't be at all surprised if something currently depends on the currently incorrect mime detection algorithm. I've not uncovered any issues with the above solution yet, but I wouldn't call what I've done thus far a terribly robust QA.

Thanks for your consideration (and an awesome distribution!)

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.