2

I just discovered that if I have a shorcut (.lnk) to a executable on my PC, and then I move the exe to another folder on the PC, the shortcut will auto-update to reflect the new location. This is happening with a almost completely patched Windows 7 (x64) PC - also confirmed on another similar W7 box.

When did this start happening? This is very surprising, considering this has not been the expected functionality since Windows' inception. (Especially bad if you rely on the old behavior of the shortcut simply failing.) Does this happen now on any other version of Windows?

Improve this question
2
  • 4
    AFAIR it's a NTFS feature and it works like that since Vista. It can be disabled by stopping Distributed Link Tracking Client service.
    – gronostaj
    Commented Dec 15, 2016 at 15:03
  • @gronostaj indeed that looks to be the reason, but that doesn't explain how the default functionality changed within the last month or two.
    – Brie
    Commented Dec 15, 2016 at 15:10

1 Answer 1

Reset to default
5

Windows has been keeping track of shortcuts for quite some time, though it has gotten smarter over the years.

In Windows 95, if you tried to use a shortcut to a file that doesn't exist, Windows would search neighboring directories for files with properties (e.g. creation time) similar to the missing one. If you moved the file too far in the folder hierarchy from its starting point, Windows would likely give up before finding it.

In Windows NT, Microsoft introduced NTFS, which is better than FAT32 in a lot of ways. Relevantly, it can assign each file and volume an object identifier. When a shortcut is broken, Windows looks up the object identifier, which remains constant no matter how much you move or rename a file inside one volume.

Further reading: Tracking Shortcuts by Raymond Chen.

In Windows 2000, Microsoft added the Distributed Link Tracking Client service. This service keeps an eye on moved files. When you move a file across volumes (thereby changing the object identifier), it makes a note of the original location and the new place. If an object identifier lookup doesn't fix a broken shortcut, the Distributed Link Tracking Client service can find it on a different drive. Observe that if you stop that service, intra-volume fixups will still work, but cross-volume moves will actually break the shortcut. On a domain, this client service works with its counterpart on domain controllers, Distributed Link Tracking Server, which can help find a missing target even if it moved across computers.

Further reading: Distributed Link Tracking on Windows-based domain controllers.

There do not appear to have been changes to this architecture recently. I also see this behavior on Windows 10. For what it's worth, shortcut tracking behavior can be changed with the policies mentioned in the Tracking Shortcuts article.

Improve this answer
3
  • Excellent history, thanks. Still odd that something changed on my one W7 PC (not connected to AD domain) within the last month or 2? This bit me on the nether-regions on a production PC last night.
    – Brie
    Commented Dec 15, 2016 at 15:38
  • 1
    @Conrad That is interesting; I'm searching through Windows update history to see if there are any relevant changes. I'll let you know if I find anything.
    – Ben N
    Commented Dec 15, 2016 at 15:40
  • 2
    @Conrad I just did some experimentation in a VM, and I found that even a Windows 7 computer that hasn't been updated since 2010 can track link targets across volumes. (It might work a little inconsistently, because the first time I tried it, the shortcut broke, but after a reformat of one volume from FAT to NTFS and a reboot, cross-volume tracking worked fine.) If the DLTC service isn't running, it definitely won't track across volumes. Note that a copy-and-delete as opposed to a move will break a shortcut.
    – Ben N
    Commented Dec 16, 2016 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .