"Λυχνίας σβησθείσης, πάσα γυνή ομοία" — Diogenis the Cynic

When I was in college back in 1993 our then UNIX operating system had a mature support for filesystem linking. It took windows 20 years and still NTFS lacks a consistent support for links. Sure, ever since windows vista we have nominal support for all varieties (including symbolic links) but the system is full of crippling exceptions instead of uniform behavior — the price you pay for incremental 'organic' addition of features over the years.

Links to files and folders are there to provide shortcut access to filesystem objects. The common type of link is the windows shortcut, a small file (with LNK extension) that redirects to the real target, so e.g. you can access a program from a shortcut on your desktop. Shortcuts are good redirectors but are distinct from the target. More advanced linking methods work so that the 'shortcut' and the target become indistinguishable.

• Hard links work for local files only, providing mirror images at different locations (must be in the same hard disk partition) without wasting extra storage space. Hard linking increases the Link stock column (see the snapshot above)
   
• Reparse points create folder junctions to redirect filesystem paths (storage space is not an issue here). Notice how junctions get the J DOS attribute and xplorer² can tell the real folder address if you switch on the Shortcut to stock column (or press <Ctrl+L> on a junction).
   
• Symbolic links are the latest addition (since Vista). Supposedly they can be used for both files and folders combining the advantages of hard links and folder junctions, including (allegedly) remote network targets. But do they?

Symbolic links are created in xplorer² (like all other links) using Edit > Paste special menu commands. There is also the console tool MKLINK if you are well'ard. The first obstacle with symlinks is that UAC blocks them, so to create one you must run elevated (Window > Administrator menu command in xplorer²). Moreover symbolic links are broken for executable files. Although you can see a symbolic link to a file in the above picture, if you click on it nothing happens but an error message "the specified path does not exist". They seem to work ok for document files though.

Another limitation of windows advanced links in general is that the shortcut and the target must be on the same computer. No direct network paths are supported; if you want to create a folder junction from your local hard disk pointing to some UNC network path (\\remotePC\share\folder) first you must create a network mapping to a drive letter. According to the manual, the advantage of the new symbolic links is that they can link to do direct network targets, which is useful.

The verdict on NTFS linking is bleak. Plain LNK shortcuts are in trouble when the target file is moved. Hard links are easily destroyed when saved, and folder junctions cannot do networks. Overall the only useful function is using folder junctions to redirect local folders to local partitions when disk space is low. It is hard to admit but for filesystem links it is Linux:1 - Microsoft:0. Perhaps in another 20 years windows will catch up?

POSTSCRIPT: The original version of this post took a negative stance on symbolic links. I had to revise my opinion after feedback indicated that they work for many file types and folders, and live to their expectation of bridging to network targets. The UAC drawback can be solved by editing group policies. So if you are on Vista or later, use them!

Post a comment on this topic