Haiku's MIME Database: Types, Attributes, App Signatures, and Preferred Handlers

On many systems, a desktop guesses file type from the extension and keeps application associations in a separate registry. Haiku can store a MIME type directly as a filesystem attribute on the file, while a system MIME database describes known types, icons, extensions, sniffing rules, and preferred applications. Tracker and applications combine those layers to present and open documents.

The distinction is important. BNodeInfo works with metadata attached to one node. BMimeType represents an installed type in the database. Updating one file’s BEOS:TYPE attribute does not automatically define the type system-wide, and installing a type does not rewrite every existing file.

MIME strings define a hierarchy

A complete type has a supertype and subtype, such as text/plain or image/png. BMimeType validates strings and can determine whether one type contains another at the supertype level. Application signatures use the application MIME namespace, conventionally with a reverse-domain identity.

Choose a stable vendor-qualified type for a private document format rather than overloading a standard type. Once files and preferred-app settings use the string, changing it becomes a migration. Keep MIME values lowercase and within the syntax the API accepts.

A type label is classification, not proof. A hostile file can carry text/plain while containing executable or malformed binary data. Parsers must validate the content they consume.

BNodeInfo writes metadata on one file

Given a BNode, BNodeInfo reads and writes the node’s type, preferred application, and icon-related metadata. On BFS, the type commonly lives in the BEOS:TYPE attribute. Check SetTo() or constructor initialization and every returned status_t.

BFile file(path, B_READ_WRITE);
if (file.InitCheck() != B_OK)
    return file.InitCheck();

BNodeInfo info(&file);
if (info.InitCheck() != B_OK)
    return info.InitCheck();

status_t status = info.SetType("application/x-vnd.example-note");

Writing attributes can fail on a read-only volume or a filesystem without equivalent attribute support. The application should still be able to inspect the document safely and should not rename it merely to simulate metadata success.

BMimeType manages the shared database entry

BMimeType can install or delete a type and manage its descriptive metadata. That includes short and long descriptions, icon data, filename extensions, attribute information, preferred application, app hints, and sniffing rules according to the API.

Installation changes system behavior for every user or application consulting that database. Perform it through the supported registration or package lifecycle, not whenever one document opens. Check whether the type already exists and update only fields the product owns.

Do not delete a shared or standard type during uninstall. For a vendor-specific type, consider whether other installed applications still declare support before removing the database entry.

Extensions and sniffing are fallback evidence

An installed type can list common filename extensions and define a sniffing rule that recognizes content. Haiku’s MIME update tools can examine files and assign types based on available evidence. A native BFS attribute can provide an immediate explicit answer, while imported files may need extension or content detection.

Sniffing rules should use stable signatures and enough bytes to distinguish the format. A generic prefix that matches unrelated data creates system-wide misclassification. Bound how much content a detector reads and handle short files.

An extension remains useful for interchange with filesystems that lose attributes. Keep extension, sniffing rule, and actual parser in agreement, but let the parser be the final authority on whether bytes form a valid document.

Preferred applications exist at two scopes

The MIME database can name the preferred application for an entire type. One file can also carry a preferred-application signature through BNodeInfo, overriding the general association for that node. This supports a user choosing a special editor for one document without changing every file of that type.

An application signature identifies the handler semantically. An app hint may help locate it but can become stale when the application moves. The roster and MIME system resolve installed applications; code should not assume the executable remains at a hard-coded path.

If a preferred application is missing, offer compatible handlers rather than failing to open the file. Do not silently rewrite the user’s association as part of fallback.

Applications publish supported types

BAppFileInfo manages application metadata, including signature and supported document types, using the representations expected for an executable. This lets the MIME system know which applications can handle a type and how to present them.

Generate application metadata during a reproducible build and package process. A signature, supported-type list, icon, and version should describe the exact signed executable. Post-install scripts that edit one representation but not another can leave resources and attributes disagreeing.

Supporting a type means the application can parse untrusted instances safely. Avoid claiming a broad supertype merely to appear in more Open With menus.

Attribute schemas improve Tracker integration

A MIME type can describe custom attributes typically associated with its files, including public names, storage types, widths, alignment, and whether Tracker should display or edit them. Applications can then make domain metadata visible in Tracker without maintaining a private catalog.

Create BFS indexes only for attributes that users will query often and use the correct attribute type. A database schema declaration does not create an index automatically on every volume. Imported files on another filesystem may not preserve those attributes at all.

Version application-specific attribute meaning. Reusing one attribute name for a different type or unit produces old files that look valid but are interpreted incorrectly.

MIME repair should be conservative

When a file opens under the wrong application, inspect its node type, per-file preferred app, installed type record, supported handlers, extension, and sniffing result separately. Do not “repair” the whole MIME database based on one mislabeled download.

Test files created locally, copied through a filesystem without attributes, downloaded with a misleading extension, renamed, moved between BFS volumes, and assigned a per-file preferred app. Verify Tracker icons, Open With choices, double-click launch, and command-line behavior.

Haiku’s MIME design works because classification travels with native files while shared behavior lives in a queryable system database. Applications should keep those scopes distinct, install only metadata they own, preserve fallback formats for interchange, and always validate document bytes independently of the friendly type attached to them.

Related:

Sources: