Windows ConfidentialTracking Shortcuts

Raymond Chen

If the target of a shortcut moves, the Windows shell will try to find the new location; this is known as "resolving" the shortcut. But what algorithm does the shell use to find that target?

The answer: It depends.

Windows 95

When shortcuts were introduced in Windows 95, file systems did not have a lot of smarts associated with object tracking. The Windows 95 shell uses a simple searching algorithm to find the lost shortcut destination: When a shortcut is created, various properties of the target of the shortcut are recorded in the shortcut file itself—properties such as the file name, file size, creation time and the last-modified time, as well as information about the drive containing the file.

These properties are updated periodically when the shortcut is used, and when the target of the shortcut goes missing, the shell starts searching for a file with as many properties as possible in common with the intended target file. When it finds a file that looks similar enough to the original target, it declares the target as having been found.

Different properties have varying importance, but creation time has the greatest weight, because that property tends to remain attached to a file even after it has been modified and even renamed. File system tunneling helps keep this information associated with the file, even when programs unwittingly operate in a manner that would normally destroy the information.

The search starts in the directory that was the file's last known location. But even locating the starting point can take a bit of work if the drive has changed; for example, if the shortcut target was on a network drive mapped to drive "O" but is now mapped to drive "P."

After searching the last-known directory, the search descends into subdirectories; then expands outward to the parent directory and sibling directories; then moves to the grandparent directory, aunts, uncles and cousins—pretty much every relative known to mankind. If the search continues for two minutes with no luck, the effort is abandoned (even if not all candidate directories have been searched).

The NT Way

The Windows NT file system folks looked at the Windows 95 shortcut resolution algorithm and scoffed. "We can do better than that: We're object-oriented!" Each NTFS object has an object identifier; a shortcut with a target that's on an NTFS volume also records the object identifier of the shortcut target, as well as the object identifier of the drive itself.

When it comes time to resolve the shortcut, the shell asks the Distributed Link Tracking Service to look for the original object. On a domain, this can produce surprising results, like finding the file even when the drive has been taken out of one computer and installed into another one.

There are a number of ways administrators can affect the algorithm the shell chooses to use. If you enable the Do not track Shell shortcuts during roaming (LinkResolveIgnoreLinkInfo) policy, the shell will not try to locate the original drive. If the shortcut target was on a network drive, the shell will not try to locate the original network resource when determining the starting location for the Windows 95-style search. It will just assume the drive letter is correct; if it isn't, well, what happens, happens.

This policy was created for environments which have a pool of identical network resources, where the load is distributed by having a login script connect the "O" drive (for example) to a different server depending on the user. Even though two users are connecting to two physically different servers, they are logically identical. If you set this policy, a shortcut to O:\program.exe will run the program currently on drive "O," even if drive "O" is not connected to the same network resource as when the shortcut was created.

There are also a pair of policies that let you disable the two object-location algorithms once the starting point has been determined: the Do not use the tracking-based method when resolving shell shortcuts (NoResolveTrack) policy disables the fancy NTFS object-tracking algorithm; the Do not use the search-based method when resolving shell shortcuts (NoResolveSearch) policy disables the low-tech Windows 95 search algorithm.

Repairing broken shortcuts is one of those thankless jobs of the shell: People don't even realize that they're relying on the feature until it stops working.

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley 2007) deal with Windows history and Win32 programming. He sometimes encodes information by translating it into German (poorly).