Directory MIME Type

What does inode/directory mean?

inode/directory identifies a filesystem directory, commonly called a folder. Unlike an image, document, or archive media type, it does not describe a sequence of bytes with a file format. It labels a filesystem object whose directory entries associate names with other filesystem objects.¹

The type comes from the freedesktop.org Shared MIME-info specification. That specification introduced the inode family for non-regular filesystem objects such as directories, symbolic links, sockets, FIFOs, and device files. It also defines inode/mount-point as a subtype of inode/directory.²

The distinction matters when an API asks for a MIME type. Sending inode/directory can be useful inside a file manager, desktop application, or storage system that explicitly understands it. It is not a portable way to send a directory over HTTP.

Why does a folder have a MIME type?

Desktop environments use content types for more than network payloads. A shared identifier lets them select an icon, describe the object, and associate it with an application. The Shared MIME-info specification explicitly names those uses for non-regular files.²

This also lets a Linux desktop associate inode/directory with its preferred file manager. The freedesktop.org MIME Applications specification defines how mimeapps.list chooses default and associated applications for a content type.⁴ Depending on the desktop, opening a directory may therefore launch GNOME Files, KDE Dolphin, Thunar, or another configured file manager.

The convention dates to the early Shared MIME-info work led by Thomas Leonard for the X Desktop Group. Version 0.7 of the specification, published in May 2002, already reserved the inode top-level name for directories, pipes, and other non-file objects.⁵

How is inode/directory identified?

A directory has no filename extension or magic number. Software identifies it from filesystem metadata, not by reading a header. POSIX file-status information distinguishes directories from regular files and other object types; the file utility is likewise required to identify a non-regular directory as a directory before content tests are attempted.⁶

That gives inode/directory different identification rules from ordinary formats:

How to open an inode/directory object

Open it with a file manager or a filesystem API rather than a media decoder. On a Linux desktop, the default application association for inode/directory normally points to the user's chosen file manager. Command-line tools can list or traverse it, subject to permissions.

Web browsers do not support inode/directory as a standard HTTP representation. A browser may display a local file: directory or a server-generated index, but that interface is created by the browser or server. It is not a decoded inode/directory payload. For web transfer, package the directory as an archive such as ZIP or expose its members through an application-specific API.

Support in Poly

Poly uses inode/directory as its first-class folder type. You can open folders to browse their children, create and move items within them, sync folder trees, share access, search within a location, and review or restore their history.

Folders are searchable by name and supported properties. The files inside a folder are processed and indexed individually according to their own formats. The folder is not flattened into one document, so it does not gain a combined text body, thumbnail, or content embedding.

The Poly agent can list, navigate, and organize folder contents when it has access to them. It can then read supported child files individually. The directory object itself has no byte stream or document body for the agent to summarize, and access to a folder does not bypass permissions on its contents.

Directory, symbolic link, and archive compared

These objects can all appear to collect or point toward other files, but they behave differently.

A symbolic link to a directory is still a link until software follows it. Following links during upload, traversal, or deletion can cross an expected boundary, so tools should define whether they operate on the link or its target.

An archive is different again. It is a byte-stream file with a format, extension, and signature. Packaging a directory as ZIP preserves a hierarchy inside one transferable file, but extracting it creates a new directory tree. Renaming a folder to .zip does not perform that packaging.

Security and interoperability considerations

Directory operations deserve path-level checks that ordinary file decoding does not:

• Enforce read, write, and search permissions at every relevant path component.
• Define whether symbolic links are followed, and guard against link-based escapes from an allowed root.
• Reject .., absolute paths, and platform-specific path tricks when materializing untrusted names.
• Expect directory contents to change between listing and opening an entry. Use filesystem operations that avoid time-of-check to time-of-use assumptions.
• Do not expose a directory listing over HTTP unless the names and metadata are intended to be public.

inode/directory tells software what kind of object it has. It does not convey permissions, ownership, contents, or whether traversal is safe.