Symbolic Links in Vista
I have been reading Hanselman's post on symbolic links in Vista and trying to get a handle on what exactly is the difference between junctions and the new UNIX-style symbolic links in Windows Vista.
Windows Vista now supports four different types of links: shortcuts, hard links, junctions and symbolic links.
Desktop Shortcuts are COM-based objects understood and maintained by the shell. Shortcut data resides in special .lnk files that store metadata such as icons and can point to files, command strings, directories and other shell objects. While these are the most common and most user-friendly links used, they are not recognized by the underlying operating system, making them almost worthless to developers.
The other types of links are handled properly in API calls, but are only available in NTFS.
Hard Links are very tight file links that seem to track the location of target within a single volume. In reality, hard links are based on the same concept in UNIX and represent an N:1 association between a file name and a data object. Each data object contains a reference count of how many file names refer to it. When all files referring to the data object are deleted, then and only then is the data object removed. Every file is thus a hard link to its data, and there is no notion of a source or target file. Hard links can only reside in a single volume.
Symbolic links and Junctions ("soft links") both use reparse points and store the string path of the target file system object. Symbolic links for both directories and files were returned when I typed "dir /aL" to list just reparse points, and there was other evidence in the MSDN pages. Unlike hard links, the target object does not actually have to be in the same volume or actually exist for either type of link.
Junctions and symbolic links for directories are similar enough that junctions were often referred to as symbolic links in past versions of Windows. There are a few differences, though:
- Symbolic links also work on files in addition to directories.
- Symbolic links store relative paths, while junctions uses absolute paths. This difference is noticeable when moving links around the file system. Symbolics links are much better for referring to nested directories.
A symbolic link is a file-system object that points to another file system object... Symbolic links are transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented its symbolic links to function just like UNIX links.
In comparison, Microsoft mentions this about junctions:
A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links. Soft links are implemented through reparse points.
Hanselman's claim that junctions don't work across volumes may have been in reference to Russinovich's warning that junctions do not work on remote shares, which is true, and his use of Russinovich's tool junction.exe, which may have an articial limitation against local volumes. I do know that junctions have always and still do work on separate volumes as this is how my development environment is set up.
The MSDN documentation implies that while junctions are essentially treated as being identical to the target directory, symbolic links are more leaky and often treated as the link files they are, resulting in a number of changes to API calls to treat symbol links specially. That is, some operations that would have operated on the target of junctions may only operate on the symbolic link itself.
Symbolic links might also treat access control differently from junctions. I read that access restrictions are ignored on the link itself in UNIX, but I doubt this is true for Windows given Microsoft's penchant for enforcing security so much so that features become completely and inexplicably inaccessible behind a cryptic "Access Denied" dialog.