Symbolic Link

A symbolic link is a special kind of file found in many modern file systems. Its own content is not data from another file. Instead, it stores the path to another file or directory. When a program or command asks for that link, the operating system kernel follows the stored path and points to the real object.

This makes the link a kind of indirection. It behaves like a shortcut in everyday use, but it works at a lower level. For most commands and applications, the difference is invisible. The process still opens the final file, not the link itself.

A link has two main parts. One part is the link file, which has its own inode. The other part is the target, the object the link refers to. The target may be a file, a directory, or even a path that does not exist at the moment.

People often compare symbolic links with hard links. The distinction matters.

  • A hard link points to the same inode as the original file.
  • A symbolic link is a separate file that holds a path string.

Because of that difference, hard links and symbolic links behave in different ways.

  • Hard links usually stay on one filesystem and cannot cross filesystem boundaries.
  • Symbolic links can cross filesystem boundaries.
  • Hard links generally cannot link directories.
  • Symbolic links can link directories.
  • Deleting one hard link does not remove the other hard link.
  • Deleting the target of a symbolic link can leave a dangling link.

On Unix-like systems, including Linux and macOS, the usual command is ln -s.

The basic form is:

ln -s target path

For example, a deployment tool might create a link named current that points to a release directory.

ln -s /srv/myapp/releases/v1 /srv/myapp/current

The result can be checked with ls -l /srv/myapp/current.

The output may show something like:

current -> /srv/myapp/releases/v1

If the target is a relative path, it is resolved relative to the directory containing the link, not the directory where the command was run. That detail surprises people who create links inside scripts.

For instance, from /srv/myapp, the command:

ln -s releases/v1 current-rel

makes current-rel point to /srv/myapp/releases/v1.

On Windows, users can use mklink. The syntax includes options for files and directories.

mklink Link Target

mklink /D LinkDir TargetDir

Creating directory links may require administrator rights or developer mode.

Several tools help inspect links.

  • ls -l shows the link and its target.
  • readlink prints the raw target path.
  • readlink -f resolves the path fully. GNU/Linux uses this. macOS may use realpath.
  • find . -type l finds symbolic links in a directory tree.
  • [ -L file ] tests whether something is a symbolic link.
  • [ -e file ] tests whether the target exists.

A valid link points to an existing object. A dangling link points to nothing or to a missing path.

To remove a symbolic link, use rm. The command removes the link itself, not the target.

rm /srv/myapp/current

To replace a link, a common option is ln -sfn.

ln -sfn /srv/myapp/releases/v2 /srv/myapp/current

The -f option forces replacement. The -n option avoids following a directory link in some cases.

Care is needed with commands such as rm -r symlink/. A trailing slash can cause the system to dereference a directory link, which may lead to removing the target directory's contents. Avoid adding a trailing slash when deleting a link.

Symbolic links are useful in many workflows.

  • Version switching: A system can point current at releases/v1 or releases/v2. Deployment then only changes the link.
  • Configuration management: Applications can read a stable path while the actual file changes.
  • Deployment: A service can use one path while operators update the target.
  • Temporary access: A link can grant quick access to a file or directory.
  • Shared resources: A link can group files without moving them.

In versioned deployments, switching a link is fast and reversible. Rolling back means pointing the link back to the old release.

Important Caveats

Symbolic links are powerful, but they require care.

  • Relative paths are resolved from the link's location, not the current working directory.
  • Dangling links may cause errors if software expects an existing target.
  • Permissions of the target are what matter when access is checked.
  • Deleting the wrong link can be risky, especially with directory links and trailing slashes.

A good habit is to check the target before relying on a link. Use readlink or realpath when debugging. Confirm that the final path is correct.

Conclusion

A symbolic link is a small but important feature of file systems. It stores a path and lets the system redirect access. Unlike a hard link, it is not the same object as the target. It can cross filesystems and can point to directories.

With the right commands and habits, symbolic links simplify version control, configuration, and deployment. Understanding how they store paths, how they differ from hard links, and how to manage them safely is valuable for developers and system administrators.