Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Windows XP and later support symbolic links. Yet, Windows continues to use shortcut files (which essentially store the location of the linked file as text). Why?

share|improve this question
25  
Why do new versions of Windows (and Office) save text files in ANSI format and not UTF-8? Either to perpetrate incompatibility and unreasonability or to support legacy systems... – retrography Feb 2 at 5:52
9  
Windows XP and later support symbolic on certain filesystems. Symbolic links work on an NTFS file system on your hard disk, but don't work if copied to a normal FAT 32 formatted USB stick, or a UDF format CD-ROM, and may not work if copied to a network server (as you often don't know the OS or file system used by the remote server). LNK shortcut files can be happily copied and work across all of those. – GAThrawn Feb 2 at 10:50
11  
Windows .lnk files are more similar to Linux .desktop files than to symlinks. – Arturo Torres Sánchez Feb 2 at 13:18
3  
Symlinks are tricky security wise (confused deputy problem) – CodesInChaos Feb 2 at 16:01
2  
So, did you stop using bookmarks in your browser when NTFS came around? It may sound like an absurd comparison, but only if you think that shortcuts are nothing but pointers to files - that simply isn't the case. – Luaan Feb 2 at 16:22
up vote 103 down vote accepted

A number of reasons, I guess

  1. You can store different levels of compatibility against several different shortcuts to the same EXE as they're interpreted by the shell, rather than the file system.
  2. Certain shortcut links don't actually exist on the file system. Some of them are simply references to GUIDs, or special strings interpreted by the shell.
  3. You can't include switches in a symlink. You can point to the EXE, sure, but you can't tell that EXE any further arguments.
  4. You can't choose an icon for a symlink.
  5. You can't choose what directory to work from in a symlink.
  6. Shortcut files don't just have to point to files, they can be hyperlinks or protocol links (In the case of a .URL file).
  7. LNK files can exist on any file system. Symlinks are handled by the file system itself, in the case of Windows, NTFS.
  8. There's no real need to replace them. They work, they're tiny, they can be scaled up in the future should there ever be a need for more functionality to be added to them than listed above.
  9. Administrative rights are required to create a symlink (For good reason - otherwise redirection of innocent files to malicious ones can be executed with very little work)

There will be more reasons than this, but I think that's enough to get you started :) - There's a link provided by @grawity here that will give some further reading on parts of this topic.

share|improve this answer
2  
Additionally, file shortcuts cache certain metadata about the target, and being interpreted at shell level allows shortcuts to be updated by the shell if the target has been moved, which would be harder with symlinks. In general, see Old New Thing again for various interesting things on shortcut features. – grawity Feb 2 at 6:03
4  
@grawity Would there be any major benefit to moving these to being handled by the file system though? I would have thought .lnk files have an infinite room to expand for further functionality if required, whilst still retaining backwards compatibility, and they've not got a lot of overhead to them. Moving this to the file system would be a little over-engineered, perhaps? I'm by no means an expert on the inner workings of file systems, though. – Jonno Feb 2 at 6:13
3  
True, the FS itself would have no use for most of this information – many .lnk features are really Explorer-specific, so storing everything as a reparse point instead of a file would be overkill. – grawity Feb 2 at 6:17
2  
Just wanted to point out, LNK files can't, as far as I know, be used to target URLs (hyperlinks). You can use the same shortcut creation facility in Windows to create a shortcut to a URL, but the end result is a .URL file (which is plain text, essentially an INI file), not a .LNK file (which is binary). – Michael Becker Feb 2 at 20:18
3  
Or start http://superuser.com which picks the default browser, like a true shortcut to a URL would do. That said, you could make .LNK files point to URL's. In the end, they're "serialized COM monikers", and the COM system can be expanded with new moniker types. – MSalters Feb 2 at 23:12

A symlink is nothing more than a path wrapped up in a very small amount of filesystem magic. There are any number of ways it can become invalid ("broken"), most of which involve one or more files or directories getting renamed. Since Windows is consumer software, you may have a large number of very poorly designed programs running on a "typical" installation. As a result, this kind of breakage is a lot harder to avoid than on a server where (in theory) every program that touches the disk is a known quantity.

Shortcuts are immune to most forms of breakage since they track their targets independently of path. This makes them more user-friendly. They are specifically designed for consumers, with a "just do what I mean and don't bother me about the details" approach.

Now, you could use hard links for that (to some extent), but hard links have a number of complicated properties which make them unsuitable for consumer use. In particular, files get new inode numbers entirely too easily and some backup software breaks rather spectacularly when confronted with hard links. The former could (perhaps) be solved with filesystem tunneling (which is in fact how shortcuts solve a related problem), but the latter is a much harder problem.

(I should probably also note that "solving" hard links with tunneling is decidedly nontrivial since it's not just a matter of reattaching metadata that's "gotten lost." Inodes are bound up in the disk allocation scheme, so you can't just arbitrarily merge or reassign them after the fact without a fair bit of legwork. Since shortcuts use other metadata that can be easily tunneled, like the creation time, they don't have this issue.)

share|improve this answer

You must log in to answer this question.

protected by Raystafarian Feb 22 at 17:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged .