How Does a Windows Shortcut Find a File You Moved? — A File's Location and Its Identity Are Two Different Things

You created a shortcut on the desktop so you could open a plan stored in the Drafts folder. Later, you moved the plan to the Submit folder.

You did not recreate the shortcut. Even so, double-clicking it can still open the plan at its new location.

Why can it find a file that is no longer where it used to be?

A shortcut remembers more than a location. It can also carry information for searching again for a target it can no longer find. This article follows that search, using an ordinary .lnk that points at a regular file.¹

1. First, Look at the Old Location

Suppose you move the plan from C:\Work\Drafts\plan.txt to C:\Work\Submit\plan.txt on the same NTFS volume.

There is still just one file, and only where it sits has changed. The path stored in the shortcut, however, still points at Drafts.

flowchart TB
    accTitle: Moving the plan splits the old path from its current location
    accDescr: The Drafts folder the shortcut remembers no longer holds the plan, and the same plan has moved to the Submit folder.
    L["Shortcut"] --> O["Drafts - not there anymore"]
    F["The same plan"] --> N["Submit - it is here"]

Figure 1: A mechanism that follows only the old location would hit a dead end here.

The Windows shell, too, first checks whether the target is at the stored location. It does not necessarily give up the moment it fails to find it there, though. Processing continues that searches again with whatever information is available. This is called link resolution.²

The .lnk file format holds more than information describing where the target is. It also has fields that record things like the creation time and the size, and extra data blocks that carry tracking information are defined on top of that. The single line shown as Target in the properties dialog is not everything a shortcut holds.³⁴

So what does it rely on when the name has changed as well?

2. Using a Name Tag That Survives a Rename

Now rename the plan you moved to Submit as proposal.txt. Both the location and the name have changed, but you moved and renamed the original file rather than creating a different one.

What helps in a situation like this is identifying information that is separate from location and name.

The Windows mechanism called distributed link tracking uses the Object ID attached to a file or folder on NTFS. An Object ID is not a required attribute; it amounts to a name tag that identifies something to be tracked. An index for looking up the Object IDs within that volume is provided as well.⁵

Suppose, for example, that the plan carries name tag K. K is a symbol used for this explanation, not the actual format of an ID.

flowchart TB
    accTitle: Identifying information that survives a move and a rename on one volume
    accDescr: When the tracking information is preserved, the same name tag is the clue for following the plan in Drafts to the proposal in Submit even though the name and the location have changed.
    A["plan.txt with name tag K"] -->|"Move and rename"| B["proposal.txt with name tag K"]
    L["Tracking information in the shortcut"] -.->|"Search with K as the clue"| B

Figure 2: Where a file is can change without the identifying information used for tracking changing with it.

When tracking information is available, the search is not limited to hunting for the old name across every folder; the target after the move can be found from the identifying information. The TrackerDataBlock in a .lnk can store the information handed to this tracking service.⁴

Changing your address does not make you a different person. In the same way, a file’s path can change while the clues for following the same file remain. That is one reason a shortcut still opens after a move.

Not every shortcut is resolved this way, though. When the name tag cannot be used, the search moves on to a different method.

3. When the Identifier Does Not Find It, Search by Characteristics

What if a nearby folder held a file with the same creation time as the original plan and similar attributes? That makes it a candidate that might be the original file under a new name.

The shell also has a search that uses characteristics like these. The official description says that when the tracking service is unavailable, or tracking does not find the target, the shell looks in places such as the original folder and its vicinity for candidates whose name, creation time, and so on match.²

The path so far can be summarized as follows.

flowchart TB
    accTitle: Shifting the clue from the stored location to tracking and then characteristics
    accDescr: If the target is not at the stored location, the available tracking information is tried, and if that still does not find it, a search by characteristics is attempted.
    P["Check the stored location"] -->|"Not found"| I["Use tracking information"]
    I -->|"Unavailable or not found"| S["Look for candidates matching the characteristics"]

Figure 3: The broad outline of ordinary link resolution. Whether tracking and searching happen at all also depends on the settings and on how the call is made.

A matching name tag and similar characteristics are not equally strong evidence. If several files share a name or a creation time, characteristics alone cannot prove which one is the real target. This is not a mechanism that compares all the content to prove identity; it is a mechanism that searches again for a target it has lost.

The search does not continue without limit, either. An application can specify flags that suppress tracking or searching, and an administrative policy can restrict them. The fact that the file opened does not by itself tell you which clue did the work.⁶

4. Is a Copy With the Same Content the Same File?

Now copy proposal.txt from Submit into Distribute. The content is the same, but there are two files now. Edit only one of them and the other keeps its content.

The Object ID is not simply duplicated by an ordinary copy either. If two files on the same volume had the same ID, the name tag could no longer tell them apart. Microsoft explains that a copy does not inherit the same Object ID as the original.⁵

flowchart TB
    accTitle: Moving a file and copying it mean different things for identity
    accDescr: Where moving keeps the same file, an ordinary copy creates a separate file that holds the content, and the original tracking Object ID is not duplicated as is.
    O["The original proposal"] -->|"Ordinary copy"| C["A separate proposal file"]
    O --> A["The original name tag"]
    C --> B["Does not inherit the same name tag"]

Figure 4: Making the content the same is not the same as moving the original file itself.

Here is one more case that catches people out. After the original plan has been moved to Submit, what happens if a different file with the same name is put at the now-vacant Drafts\plan.txt?

As section 1 described, the stored location is normally checked first. If a target is found there, the process may never reach the stage of looking for the new location. In other words, even with tracking in place, there is no guarantee that the original file you moved is the one that gets chosen.¹

A shortcut is a convenient entry point for finding a target it can open right now. It is not a mechanism for proving, every time, that this is the same file as before. Once you hold on to that distinction, the convenience and the limits fit together.

5. Follow the Same File on Your Own PC

If you try this, use a text file created in a local test folder rather than a work document. Start by creating Drafts and Submit on the same NTFS volume, and keep the conditions narrow by avoiding synced folders and network shares.

Create a file in Drafts, create a shortcut to it, and confirm that it opens from there. Next move only the file itself to Submit and open the shortcut. Then rename the file and try once more. Each time, check which file actually opened.

What you are watching for is whether the shortcut reaches the new location once the old one is no longer usable. If it does not open, that does not contradict this article. The result changes with the conditions under which NTFS tracking is available, the information that remains, the settings, and so on. Do not expect the same result once a file moves to a USB drive or another PC.⁵⁶

While writing this, I also confirmed the behavior with IShellLinkW::Resolve on local NTFS under Windows Server 2025 (build 26100). After a move and a rename, the new path came back, and in a separate trial where a different file was placed at the original location, the old path came back. This is an observation of the API in one environment, not a test through the File Explorer UI on Windows 11 and not a verification of which internal search path was used. The observation record is available as well.

To run the comparison where a different file is placed at the original location, start over from scratch with a different test file. A shortcut that has been resolved once can have its link information updated, so reusing the same shortcut may mean it no longer points at the old location.²

6. For Developers: Reading a Path Versus Searching Again

When an application works with a .lnk, keep reading the stored information separate from searching for a target that has been lost. Getting the path with GetPath on IShellLink and attempting link resolution with Resolve are not the same operation.⁷

flowchart TB
    accTitle: Load the shortcut and then resolve the target
    accDescr: Load the link with IPersistFile, attempt resolution with Resolve, and get the resolved path with GetPath after confirming that it succeeded.
    L["Load the link"] --> R["Try to resolve with Resolve"]
    R -->|"Confirm success"| G["Get the path with GetPath"]

Figure 5: Reading the string for the original location is not the same as having searched for the new one.

In automated processing, the UI shown when nothing is found, the time spent searching, whether tracking is used, and whether the link information is updated are design decisions too. For example, SLR_NOSEARCH suppresses the search by characteristics and SLR_NOTRACK suppresses the use of distributed link tracking. Choose the flags to match your purpose, and do not treat opening just anything as success.²

Note that the tracking Object ID and the file ID obtained from a file handle are not the same item. Comparing file IDs involves the volume as well. Do not lump them together because both are called an ID; check which identifier from which API you are dealing with. There is no need to rewrite an Object ID by hand.⁸⁹

Also, the .lnk discussed here is a shell file. It differs from a symbolic link, which works within file system path resolution, so this account of searching cannot simply be transferred to that.¹⁰

A shortcut remembers more than the old address. If the location does not find the file, it uses tracking information, and if that is unusable, it searches by characteristics. That is why it can sometimes follow a move or a rename. And once copies with the same content, or a different file placed at the original location, are in the picture, it cannot always pick the original target.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (5 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Related Articles

• Safe Removal of a USB Drive and the Write Cache

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Why does a shortcut still open after the original file is moved?

Because an ordinary .lnk shortcut can search again using available tracking information and the file's characteristics when the stored path does not find the target. It is not merely a path string. Depending on the file system, the settings, and the conditions of the search, however, the target may still not be found.

Does a shortcut compare file content to find the original file?

The link resolution described here uses the path, the NTFS tracking identifier, and things like the name and creation time. It is not a mechanism that proves a file is the original by matching content. Even if you copy identical content, that copy is a different file.

If a different file with the same name is placed at the original location, will the moved original open?

The original file will not necessarily be the one that opens. Ordinary link resolution checks the stored path first, so the different file at the original location may be treated as the target. Do not rely on automatic tracking as a guarantee that a specific file is always chosen.

Is tracking guaranteed after moving a file to a USB drive or another PC?

It is not guaranteed. NTFS tracking and the search by characteristics are separate mechanisms, and the destination file system, the tracking information that remains, services and policies, and connection state all come into play. Handing someone only the shortcut does not hand over the target file itself.

Are a shortcut and a symbolic link the same thing?

They are different. A .lnk is a file that the Windows shell reads in order to resolve the target. A symbolic link is a separate mechanism that takes part in file system path resolution, and the search behavior of a .lnk does not carry over to it.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.