blob: c3ece239cdec79d7276d849862c08e192cee74ce (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
+++
date = 2024-09-28T18:23:12+02:00
title = "MIME type subclassing and its consequences"
[taxonomies]
tags = ["TIL"]
[extra]
related = []
+++
The freedesktop.org [shared MIME-info database
spec](https://specifications.freedesktop.org/shared-mime-info-spec/latest) says
the following in [section
2.11](https://specifications.freedesktop.org/shared-mime-info-spec/latest/ar01s02.html#subclassing):
> A type is a subclass of another type if any instance of the first type is
> also an instance of the second. For example, all `image/svg+xml` files are
> also `application/xml`, `text/plain` and `application/octet-stream` files.
> Subclassing is about the format, rather than the category of the data (for
> example, there is no 'generic spreadsheet' class that all spreadsheets
> inherit from).
>
> Some subclass rules are implicit:
> - All `text/*` types are subclasses of `text/plain`.
> - All streamable types (ie, everything except the `inode/*` types) are subclasses of application/octet-stream.
So far so good; this makes intuitive sense and seems sensible enough. There is
an interesting consequence of this rule when the MIME-info database is used by
desktop systems for file associations, however: **An application associated with
`application/octet-stream` will automatically be associated with all streamable
types as well.**
This means that if you associate `application/octet-stream` with your text
editor, your desktop system will also suggest you open video and audio files
with that same text editor. This behaviour can be quite surprising, especially
if the association was added automatically when a file was opened through the
"Open with..." dialog.
What is even more confusing if you don't happen to know the subclassing rule is
the fact that `~/.config/mimeapps.list` and applications interfacing with this
file will not even list the editor as associated with any audio or video files.
You might just skip over the entry it has for `application/octet-stream`, not
realizing its significance. Perhaps you even assume (understandably) that
`application/octet-stream` only specifies any file of "unknown" type.
User-facing documentation on desktop systems (if it even exists) does not
discuss this behaviour.
Whilst looking into this I found an older KDE bug report with some [interesting
thoughts](https://bugs.kde.org/show_bug.cgi?id=425154#c2) on how to explain this
behaviour to the end user, but sadly as far as I have seen none of these have
made it into the system setting's file association dialog.
|
