69

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?

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Alex
  • 855
  • 1
  • 7
  • 11
  • 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 02 '16 at 05: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 02 '16 at 10:50
  • 12
    Windows `.lnk` files are more similar to Linux `.desktop` files than to symlinks. – Arturo Torres Sánchez Feb 02 '16 at 13:18
  • 3
    Symlinks are tricky security wise (confused deputy problem) – CodesInChaos Feb 02 '16 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 02 '16 at 16:22
  • @retrography And in Windows 10 Notepad is still the one and same old code as in Windows 3.1... –  Feb 03 '16 at 09:38
  • @Nasha no, there are many changes in Notepad in each Windows version. Do you find Unicode support in Windows 3.1's notepad? Or the [Bush hid the facts](https://en.wikipedia.org/wiki/Bush_hid_the_facts) bug only appears in windows NT 3.5 through XP but not in Windows 98's – phuclv Feb 03 '16 at 13:16
  • @Nasha Aside from Lưu Vĩnh Phúc's comment, the old Windows 3.x lineage ended with Windows Me, which was the follow-up to Windows 95 and 98. (Not to be confused with Windows 2000, which was the follow-up to Windows NT 4.0.) Modern versions of Windows trace their lineage back to Windows NT 3.1, which was the first release in the Windows NT line. – user Feb 03 '16 at 15:13
  • @Lưu Vĩnh Phúc The code may be different but Notepad's features are still the same as 20 years ago (yeah, right, it saves in UTF-8), e.g. Ctrl+BkSpace still prints a square instead of deleting one word backwards... –  Feb 05 '16 at 13:48
  • @LưuVĩnhPhúc It's worth noting that the second issue you call out is directly tied to the first - they're not really separate examples of changes to Notepad. The "Bush hid the facts" bug was introduced as a direct result of code that was added for Unicode support, starting with NT 3.5. This is made fairly clear by the Wiki article you linked. In fact, it's likely the bug wasn't part of Notepad at all - some other text-editing applications exhibited the same issue (again, in the Wiki), probably due to a bug in an OS-provided function instead of the application itself. – Iszi Feb 09 '16 at 15:11

2 Answers2

108

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.

Jonno
  • 21,049
  • 4
  • 61
  • 70
  • Your #2 is two different reasons mixed up into one. It's true that shortcuts can point to non-filesystem paths, but it works in a _different_ way than merely running `explorer` with a magic switch (that would be merely repeating #3). Among other targets, there can be shortcuts to MSI "advertised" apps, for example. See [Old New Thing](https://blogs.msdn.microsoft.com/oldnewthing/20121210-00/?p=5883/). – u1686_grawity Feb 02 '16 at 06:00
  • @grawity Changed it to be a little more generic – Jonno Feb 02 '16 at 06:02
  • 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](https://www.google.com/search?ie=UTF-8&q=site%3Ablogs.msdn.com%2Fb%2Foldnewthing%20shortcut) for various interesting things on shortcut features. – u1686_grawity Feb 02 '16 at 06:03
  • That said... NTFS supports various kinds of reparse points, not just symlinks – other common types are junctions and mountpoints. So I suppose .lnk-based shortcuts _could_ have been turned into a special reparse point type, one that stores _all_ the information that a .lnk file could store. So it's worth asking why _that_ hasn't been done, and I imagine the answer is 1) compatibility with non-NTFS filesystems (e.g. FAT), and 2) the need for Administrator privileges to create a reparse point. – u1686_grawity Feb 02 '16 at 06:06
  • 5
    @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 02 '16 at 06: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. – u1686_grawity Feb 02 '16 at 06:17
  • 3
    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). – slickdeveloper Feb 02 '16 at 20:18
  • @MichaelBecker You can target `"C:\Program Files (x86)\Internet Explorer\iexplore.exe" http://superuser.com`, which passes the URL as an argument to Internet Explorer. This is truly still a link to a file, not the URL itself, but to the end user, it appears to be a .lnk to a URL. – thunderblaster Feb 02 '16 at 22:15
  • 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 02 '16 at 23:12
  • @MichaelBecker Thanks - I didn't expect this to get so popular and just noted down what I was thinking at the time, so I've amended that point :) – Jonno Feb 03 '16 at 05:47
  • 1
    Also: I think LNK files aren't only storing the path. Sometimes they can still work if you move the target file, as I remembered. – user23013 Feb 03 '16 at 13:02
  • 1
    @user23013: That's because of Explorer's [Link Tracking](https://technet.microsoft.com/en-us/magazine/2009.10.windowsconfidential.aspx). – afrazier Feb 03 '16 at 17:57
  • Point 8 is enough. If it's not broken, don't fix it – edc65 Feb 04 '16 at 15:41
  • 1
    Points 1-7 could all be summarized under: "Shortcuts are handled by the shell, instead of the file system, which enables a number of additional features and forward flexibility while retaining compatibility with current, future, and legacy file systems." – Iszi Feb 09 '16 at 14:48
6

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.)

Kevin
  • 161
  • 6