"application/vnd.70mai.txt" interfering with creating and opening text files

A recent update to GPXSee has introduced support for a MIME type of application/vnd.70mai.txt (Google tells me this is some dashcam format).

I do not know what is actually performing the MIME type detection (some KDE / Plasma / Qt library or component?) but it’s deciding that an empty, zero byte text file with a *.txt extension counts as this obscure dashcam format rather than the more sensible “this is an empty plain text file”.

As a result, if you create an empty text file (e.g., via the Dolphin context menu¹), it will end up opening in GPXSee rather than Kate / KWrite.

I’ve no idea where this is coming from so that I can open a bug report in the relevant project. Can anybody help with this?

¹ On some installs / for some users, Create New → Text File… results in a two-byte file containing a newline; for others it results in a zero-byte file with a *.txt extension. It’s the latter that’s the problem.

Can you post

grep -F '*.txt' /usr/share/mime/globs*

Looks like a KDE specific issue, on Gnome creating an empty file (e.g. via touch test.txt) makes the file regularly open in “Text Editor” (or whatever default you may have for .txt files).

And you have gpxsee installed?

Yessir…

LT-B:~ # zypper se -i gpxsee
Loading repository data...
Reading installed packages...

S  | Name   | Summary                                      | Type
---+--------+----------------------------------------------+--------
i+ | gpxsee | GPS log file visualization and analysis tool | package
LT-B:~ # grep -F '*.txt' /usr/share/mime/globs*
/usr/share/mime/globs:text/plain:*.txt
/usr/share/mime/globs:application/vnd.70mai.txt:*.txt
/usr/share/mime/globs2:50:text/plain:*.txt
/usr/share/mime/globs2:50:application/vnd.70mai.txt:*.txt
LT-B:~ #

Seems so.

bor@uefi:~> touch /tmp/foo.txt
bor@uefi:~> gio info -a standard::content-type /tmp/foo.txt
uri: file:///tmp/foo.txt
local path: /tmp/foo.txt
unix mount: /dev/sda2[/@/tmp] /tmp btrfs rw,relatime,seclabel,discard=async,space_cache,subvolid=260,subvol=/@/tmp
attributes:
  standard::content-type: application/x-zerosize
bor@uefi:~> kmimetypefinder /tmp/foo.txt
application/vnd.70mai.txt
bor@uefi:~> echo 123 > /tmp/foo.txt
bor@uefi:~> gio info -a standard::content-type /tmp/foo.txt
uri: file:///tmp/foo.txt
local path: /tmp/foo.txt
unix mount: /dev/sda2[/@/tmp] /tmp btrfs rw,relatime,seclabel,discard=async,space_cache,subvolid=260,subvol=/@/tmp
attributes:
  standard::content-type: text/plain
bor@uefi:~> kmimetypefinder /tmp/foo.txt
text/plain
bor@uefi:~> 

KDE violates Shared MIME Specification here. When multiple MIME types match for a file name pattern, application is expected to check magic.

bor@uefi:~> echo -n '$V02' > /tmp/foo.txt
bor@uefi:~> gio info -a standard::content-type /tmp/foo.txt
uri: file:///tmp/foo.txt
local path: /tmp/foo.txt
unix mount: /dev/sda2[/@/tmp] /tmp btrfs rw,relatime,seclabel,discard=async,space_cache,subvolid=260,subvol=/@/tmp
attributes:
  standard::content-type: application/vnd.70mai.txt
bor@uefi:~> kmimetypefinder /tmp/foo.txt
application/vnd.70mai.txt
bor@uefi:~> 

Although zero file size is certainly a special case. We cannot really predict the file content so we also cannot guess what file type user had in mind. GNOME looks more consistent here by giving generic “I do not know” answer.

The only solution would be giving text/plain higher priority.

Testing with Leap 15.6 and KDE 5:

:~> touch test.txt

– opens with Kate as simple text file.

In Dolphin check File properties → which application is dedicated.

No wonder that it works with Leap as the new MIME type was introduced by a GPXSee version which is only available for Tumbleweed in the official repos (see first post).
Issue is easily reproducible on Tumbleweed.

Even if you change the standard file association (to open with kate), an empty txt file is still seen as vnd.70mai file.