« NStatic Status | Main | Symbolic Links Redux »

October 03, 2006

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.

Microsoft says symbolic links are designed to preserved UNIX idiosyncrasies. They may have been swiped from Windows Services for UNIX.

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.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8345242f069e200d83465be6369e2

Listed below are links to weblogs that reference Symbolic Links in Vista:

» re: Windows Vista 体験記 - mklink from 囚人のジレンマな日々
re: Windows Vista 体験記 - mklink [Read More]

Comments

The way I understand it is, junctions are a trick to get part of the directory to reread itself, ie say there's a pointer in each directory that points to its children, with junction points, you set the pointer to some existing tree. They're somewhat akin to *nix's mount -o bind

Symbolic links are based purely on names, they have nothing to do with contents. When the fs looks up a name, if it encounters a symlink it starts over again with what the symlink points to (so you have to check for loops and what)

Symlinks in *nix can have permissions, but almost never do because it makes no sense.

Paul's comments sounds plausible.

So, symbolic links may not actually be reparse points, a mechanism that is probably limited to directories.

As a result, API functions need to be changed to specifically handle symbolic links which are just regular files.

One point I used linkd.exe from the Windows Resource Kit not junction.exe, so junction.exe may have limitations on the drive support.

I mostly use junctions to chain link drives together in creative ways. Say an application wants to put it's cache in one place and no option to move it...

Junctions can only be 16 deep. More then 16 junctions and an error is returned.

A good tool for creating junctions & hardlinks is "NTFS Link" (it's open source so it shouldn't be a problem to add Symbolic Link support). It encorporates nicely into Explorer.

I moved the directory "C:\Users\MyName\Documents" to "D:\MyName". After doing so, the symlink "C:\Users\MyName\My documents" is broken and points to a non-existing directory. (Everybody, who moves his user files to a separate data partition, will probably face this problem)

Did you ever try to rebuild the symlink "My documents" as Scott Hanselman wrote in his blog http://www.hanselman.com/blog/MoreOnVistaReparsePoints.aspx ?
I did, but my self-made link behaves differently than the original one, even after adapting the access control settings (see below). Clicking on my self-made link leads me through two UAC dialogs, whereas clicking on the original link blocks any access. What is the difference?

Here is, what I did:

- C:\Users\MyName> mklink "My documents" D:\MyName
- New security setting (DACL):
--- Add user "Everyone" with the following permissions: List Folders/Read Data: Deny
--- Change the owner of the link to SYSTEM

Thank you for any idea.
Best regards
Stef

Oh sorry, there is a typing error in my post: It should be: mklink /d "My documents" D:\MyName

this is good site for cheap software


http://www.goodsoftwarefindr.com

The comments to this entry are closed.