What is the difference between a Symbolic Link and a Shortcut?
I think the important point is that shortcuts are just a file. They have a size (A small one, that just references where they point) and they require an application to support that filetype in order to be used.
A symbolic link is filesystem level, and everything sees it as the original file. An application needs no special support to use a symbolic link.
|show 1 more comment|
A "Symbolic Link" can actually act like a substitute for a directory or file in a functional way, and is commonly used in Unix/Linux environments. Although there is apparently support for this in Windows, I haven't seen any actual use of it yet.
A "Shortcut" is just a regular file that has a reference to the destination file or directory along with some other things like the icon to be displayed. Unlike a Symbolic Link, you cannot "cd ./shortcut-name" in DOS (in Unix/Linux you can "cd ./symlink-name" and it will work just like a real sub-directory).
Also, in most Windows applications, when you click on a Shortcut in any File->Open GUI dialogue, your filename field gets populated with that shortcut's filename as well as it acting like a sub-directory, while in Unix/Linux the GUI treats a Symbolic Link as a path (without modifying the filename field).
As others have mentioned, a symbolic link is one of the kinds of links available at the file system level, which makes it transparent to applications. I've found this documentation very helpful (esp. the "Crop/Unroll/Splice Outer Junctions/Symbolic Links" section). And the tool there looks nice too. (By mentioning this, and mklink, hopefully more searches will find this discussion.)
A shortcut is a file, not a real link, and it is generally only followed successfully as a link when interpreted by the Windows UI (user interface). For example, when you double-click on a folder shortcut, Windows redirects you to that other location. (This includes the generic File Open and File Save dialogs that most applications invoke.) On my desktop, I have a shortcut to this folder: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\G
The shorcut's filename is: C:\Users\user5\Desktop\Games.lnk, although Windows suppresses the .lnk extension and just shows "Games", even if you untick "hide extensions for known file types". But if you open a command prompt and do a dir, you'll see it:
I can create the equivalent with a symlink by using the \D option (for directory):
(A directory junction (\J) is an option too, since this is a folder link.) Windows explorer, just like this console and most applications, will let you browse "down into" this apparent subdirectory, rather than (a) redirecting "across" to a different location or (b) failing.
Shortcuts do not behave like subdirectories. I can invoke the Windows UI's default file behavior with this command (this opens the "G" folder in Windows Explorer):
Whereas mysymlink is listed (see the count) as a true subdirectory and can't be launched in that way:
Conversely, you cannot change-directory into a shortcut:
The Windows UI lets you right-click to edit a shortcut's properties. Or, the following shows exactly what is actually stored in the .lnk file (binary data), though a hex editor would display better:
Whereas trying to execute Notepad on a actual subfolder pops up an "Access is denied" error message, and an empty Notepad:
Conversely, if I make a file symlink (not a folder symlink), I can launch it with Notepad. Of the following notepad.exe calls, the first two work, and the third fails (it opens up the .LNK file, the binary gobbledegook).
This isn't just a console thing. Copying a shortcut to Notepad to my desktop and trying dragging and dropping each of the three onto it, it exhibits the exact same behavior. (Because drag and drop, unlike double click, lets the application interpret the shortcut.)
"A major difference in the way Windows resolves symbolic links and directory junctions is where the processing takes place. Windows processes symbolic links on the local system, even when they reference a location on a remote file server. Windows processes directory junctions that reference a remote file server on the server itself. Symbolic links on a server can therefore refer to locations that are only accessible from a client, like other client volumes, whereas directory junctions cannot. To address this, Windows Vista supports the new symbolic link type for both files and directories.
"Many file system commands have been updated to understand the implications of symbolic links. For example, the Delete command knows not to follow links, which would result in deletion of the target, but to delete the link instead. However, because not all applications may handle symbolic links correctly, creating a symbolic link requires the new Create Symbolic Link privilege that only administrators have by default."