Is a symbolic/soft link similar to a shortcut/alias on a PC?

Question

It sounds to me like the basic idea of soft/symbolic links compared to shortcuts (on a PC) or aliases (on a Mac) are the same thing. Am I way off? Are they similar?

Solution 1

The basic idea is about the same. A symbolic link is a special file that contains a path (relative or absolute) to another filesystem object. In UNIX/Linux, the OS itself processes the symbolic link, resolving to the real object transparently.

On Macs, an alias seems to be a special Finder construct can reference remote objects as well as local ones, but Finder resolves the reference, not the OS. MacOS X also has symbolic links, but they are separate from aliases.

The big difference is between a Windows shortcut and a symbolic link. A Windows shortcut cannot easily replace a program because Windows always has to have these pesky file extensions and a "lnk" file is not an executable when it comes to Windows. Within the GUI, it works, but from a server standpoint, it barfs. Same with a directory. They are useful, but do not have anywhere near the power and flexibility of a symbolic link.

Solution 2

Not really. There is a resemblance, but only up to a point. I have known people to think “ok, symlinks are like shortcuts, but I don't quite understand them” up to the point when they said “oh, actually symlinks are not like shortcuts, and now I understand them”. So I think shortcuts are not a good way to understand symbolic links and I recommend to clear your mind of the comparison with shortcuts.

A symbolic link indicates the name of another file. That's "name" as in the full path, i.e. potentially including a directory part as well as the name inside the directory. The path can be absolute (/foo/bar) or relative (foo/bar or ../bar or just bar); if the target is given by a relative path, it's interpreted relative to the directory containing the symbolic link. The target file may or may not exist, and removing, moving or creating the target file will not affect the symbolic link.

Operations that act on the file's content act on the target file. Thus when you read or write to a file through a symbolic link, or execute a program through a symbolic link, it's as if you were accessing the target file. Operations that act on a file from the outside, such as renaming or deleting, act on the symbolic link itself. Note that for writing, it makes a difference whether you overwrite the existing file (which will act on the target) or remove the existing file and create a new file (which will leave the target intact and create a new file replacing the symlink, unless the application takes care to follow the link (many do)).

Solution 3

To add to what @Giles said.

Sym-links are in all modern Unixes (UNIX, Gnu/Linux, Linux (is it is done in the kernel), MacOS, BSD, QNX). MS-Windows also has them, but are disabled by default (last time I checked). Do not confuse Mac short-cuts with sym-link, they are not the same.

If a program tries to assess a file that is a sym-link to another file, then it will access the target. This will even work on a program that does not know about the idea of sym-links.

• Unix sym-links:

  • Automatic traversal: Programs don't need special code to traverse. It just works, up to about 100 hops.
  • Creation: Needs special system call.
  • Only works on Unix file-systems.

• MS-Shortcuts

  • MS-Windows programs need to be written to know about the idea of short-cuts.
  • Traversal is limited to 1 hop.
  • Works on any file-system (without long-filename support, you are limited to 8 characters).
  • They are just files, and in theory can be created in the same way as any other file. However last time I checked it was poorly documented.

Design philosophy.

Sym-links

When sym-links were invented, it needed a change to the operating-system, and to the file-systems. However all existing programs suddenly gained the ability to traverse them. Whether desktop, command-line, service or other.

File Short-cuts

When Short-cuts were invented, and added to MS-Windows, no change to the operating-system or file-system was needed. However all program that traverse them needed to be changed. This is why the file-explorer is often the only program that traverses them, or programs that use the file-explorer as their file-loader.

Comments

[Admin]

I agree with the accepted answer. I'll just add that on Windows there are also symlinks (symbolic links, mklink command to make a new one), junction points, directory hard links, and hard links, file hard links. Actually by default there's a junction point on root directory of new Windows installations, documents and settings -> Users for compatibilty to older Windows versions apparently.

[Admin]

A symbolic link doesn't always constitute a full path: on my Slackware 13.1 system, /usr/lib/libXv.so is a symbolic link to libXv.so.1.0.0 . No full path there.

[dash17291]

"Same with a directory": Do you mean that one cannot cd in a symlink pointing to a directory?

[Arcege]

Meaning that you cannot cd to a shortcut on a Windows system since it is a Windows construct, not DOS. With UNIX/Linux, it is a filesystem construct, so it will work anywhere, including the cd command - it is up to the command to interpret the end point, not the OS. For example, cd could use a symlink to a directory, but it would properly fail on a symlink to a regular file.