Symbolic Link MIME Type

What does inode/symlink mean?

inode/symlink identifies a symbolic link, also called a symlink or soft link. A symbolic link is a special filesystem object whose content is a pathname referring to another name. It points to a path rather than directly to the target object's inode, so it can refer to a file or directory on another filesystem. Its target does not have to exist.¹

The type belongs to the inode family defined by the freedesktop.org Shared MIME-info specification. That family describes non-regular filesystem objects such as directories, sockets, FIFOs, device files, and symbolic links.²

The convention appeared during the early effort to unify the MIME databases used by GNOME, KDE, and ROX. Version 0.7 of the Shared MIME-info specification, published in May 2002 for the X Desktop Group, reserved the inode top-level name for non-regular filesystem objects.³

This distinction matters when software asks for a MIME type. inode/symlink is useful to a file manager or storage system that explicitly understands filesystem objects. It does not define a portable HTTP representation or a standalone interchange format.

How is an inode/symlink object identified?

A symbolic link has no filename extension or magic number. Software identifies it from filesystem metadata. On POSIX systems, lstat() reports information about the link itself, while stat() normally follows the link and reports information about its target.⁵

The stored pathname can be absolute or relative. A relative target is interpreted from the directory containing the link, not from the process's current working directory.⁶ Moving that link to another directory can therefore change what it resolves to or make it dangling.

How to open or inspect a symbolic link

Most file managers display a symbolic link with a link emblem and open its target when activated. On a command line, ls -l commonly shows the stored target, and readlink reads that pathname without opening the destination. Development tools should use link-aware filesystem APIs when they need to inspect, move, or remove the link itself.

A dangling link still exists even though following it fails. This is expected behavior, not proof that the directory entry is corrupt. The target may be temporarily unavailable, mounted elsewhere, or intentionally created later.

Web browsers have no standard inode/symlink payload to decode. A local file: URL may follow a link according to the browser and operating system, but that behavior is filesystem navigation rather than media-type support.

Support in Poly

Poly recognizes inode/symlink as a filesystem-object identifier, but symbolic links cannot currently be imported as link objects. They therefore do not receive a separate preview, content or metadata indexing, or agent access through the link.

If you need the destination in Poly, import the target file or folder itself. This captures that object at the location you selected rather than preserving a live filesystem reference. A later change to the original target is not represented as a symbolic-link update.

Symbolic link, hard link, and shortcut compared

These mechanisms can all look like references, but they have different identities and portability.

A hard link refers to the same underlying object as another hard link. Deleting one name does not remove the object while another hard link remains. A symbolic link instead refers to another pathname, so renaming or deleting the target can leave a dangling link.¹

A desktop shortcut is an ordinary file or application record. Examples include Windows .lnk, macOS bookmark data, and internet shortcut files. Their formats, metadata, and resolution rules are not described by inode/symlink.

Can a symbolic link be converted?

There is no general media conversion because a symbolic link is a filesystem relationship, not a byte-stream format. The useful operation depends on the goal:

• Copy the target's contents when you need a self-contained regular file.
• Create a platform shortcut when the recipient needs an application-level reference.
• Archive the link with a format such as TAR when preserving Unix filesystem metadata matters.
• Resolve the link and archive the target when portability matters more than preserving the relationship.

Archive behavior varies. Some tools preserve the link and its pathname, while others follow it and store the destination. Check the tool's link-handling option before packaging or extracting important trees.

Security and interoperability considerations

Following an untrusted symbolic link can move an operation outside the directory a user appeared to select. A link may point to an absolute path, use parent-directory components, form a loop, or change between validation and use. Linux also documents special “magic links” in pseudo-filesystems such as /proc; these do not behave exactly like ordinary pathname-based links and have been used as attack vectors.¹

For link-aware file operations:

• Decide explicitly whether each operation acts on the link or follows its target.
• Resolve relative targets from the link's containing directory.
• Keep traversal inside an allowed root using filesystem APIs designed for that constraint.
• Detect loops and apply a limit to repeated link resolution.
• Avoid a separate check-then-open sequence when another process could replace a path between those operations.
• Treat archive entries containing links as untrusted paths during extraction.

inode/symlink describes the object type. It does not say whether the target exists, where resolution ends, what permissions apply there, or whether following the link is safe.