{
  "slug": "symbolic-link",
  "term": "Symbolic link",
  "aliases": [
    "symlink",
    "soft link"
  ],
  "definition": "A symbolic link is a filesystem object that stores a pathname to be interpreted when an operation follows the link.",
  "note": "An ordinary symlink names a path rather than holding its referent's inode alive. Its stored target may be absolute or relative; a relative target starts from the directory containing the link, not the caller's working directory. The target need not exist; a dangling link can still be inspected with lstat() and readlink(), while stat() follows the link. [linux-stat-2] [linux-readlink-2] [linux-symlink-2]\n\nOn Linux, rename() and unlink() act on a final-component symlink itself. Renaming a distinct regular file over the link replaces the link entry, not the referent's contents. Moving a relative symlink to another directory may change its destination. [linux-rename-2] [linux-symlink-7]\n\nProcfs magic links, such as /proc/pid/fd entries, are different. They can refer directly to a kernel file handle rather than expanding an ordinary stored path. [linux-symlink-7]\n\nPreserving stored link text during backup does not by itself preserve the resolved destination after relocation. Whether a restore should retain the link object or copy its referent is part of the recovery policy, not a property established by equal link text. [linux-symlink-7]\n\nAt the C API, readlink() neither NUL-terminates nor signals truncation with an error. A capacity-sized return needs a larger bounded retry or an incomplete-capture error; lstat() sizing can become stale. Linux readlinkat(fd, \"\", ...) on an O_PATH | O_NOFOLLOW descriptor reads that held link, even after pathname replacement, but does not bind its referent. Language wrappers may allocate buffers internally. [linux-readlink-2]",
  "advantages": [
    "Can refer to directories and cross filesystem boundaries."
  ],
  "limitations": [
    "Does not provide an independent copy of the target's data.",
    "Stored target text does not guarantee that a later lookup reaches the same object."
  ],
  "related": [
    "path-resolution",
    "hard-link",
    "inode",
    "atomic-rename",
    "unlink",
    "open-file-description"
  ],
  "status": "shipping",
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-11-03",
  "citations": [
    {
      "id": "linux-symlink-2",
      "title": "Linux man-pages: symlink(2), target interpretation and dangling links",
      "url": "https://man7.org/linux/man-pages/man2/symlink.2.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "linux-symlink-7",
      "title": "Linux man-pages: symlink(7), link handling and magic links",
      "url": "https://man7.org/linux/man-pages/man7/symlink.7.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "linux-rename-2",
      "title": "Linux man-pages: rename(2), symbolic-link operands",
      "url": "https://man7.org/linux/man-pages/man2/rename.2.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "linux-stat-2",
      "title": "Linux man-pages: stat(2), link versus referent metadata",
      "url": "https://man7.org/linux/man-pages/man2/stat.2.html",
      "accessed": "2026-11-03"
    },
    {
      "id": "linux-readlink-2",
      "title": "Linux man-pages: readlink(2), stored link contents",
      "url": "https://man7.org/linux/man-pages/man2/readlink.2.html",
      "accessed": "2026-11-03"
    }
  ],
  "provenance": [
    "Ordinary symlink semantics are described separately from Linux procfs magic links; no crash-survival guarantee follows from these namespace rules."
  ]
}