What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Inspect the folder path itself instead of judging its icon or contents. In PowerShell, run Get-Item -LiteralPath 'C:pathtofolder' | Format-List FullName,Attributes,LinkType,Target,LinkTarget. A populated link type or target indicates that the path redirects elsewhere. If the result is unclear, query the filesystem metadata with fsutil reparsepoint query "C:pathtofolder". These checks distinguish a redirected directory from an ordinary, independent copy, while also showing when the item is a junction or another kind of reparse point rather than a symbolic link.
What you are actually trying to identify
Windows can make a directory path lead to another location in several different ways. A directory symbolic link and a directory junction are both links: applications open the link path, but the data lives at a target path. An ordinary copy has its own directory entries and contents; changing one tree does not inherently change the other.
As an Amazon Associate I earn from qualifying purchases.
The word “link” is not specific enough for troubleshooting. A symbolic link, a junction, and a reparse point implemented by another filesystem component have different semantics. Hard links are a separate case that applies to files, not directories. Start by identifying the exact path, then determine what metadata Windows reports for that path.
Free tools Windows power users keep installed
One-click scans. No signup required.
Fastest check: inspect the folder in PowerShell
Run Get-Item against the exact path
- Open PowerShell.
- Replace the example path with the folder you want to test and run:
Get-Item -LiteralPath 'C:pathtofolder' | Format-List FullName,Attributes,LinkType,Target,LinkTarget - Read the fields for
LinkType,Target, andLinkTarget. A reported link type or a target path is evidence that the item is redirecting to another location.
-LiteralPath tells PowerShell to use the path exactly as written, which avoids wildcard interpretation. Get-Item examines the folder object at that one path; it does not infer an answer from the folder’s name, icon, or apparent contents.
#1 Best Overall
How to interpret the output
| PowerShell result | What it tells you | What to do next |
|---|---|---|
LinkType and a target are populated |
The path is being reported as a link and Windows has exposed where it points. | Record the target and identify whether the link type is symbolic or junction. |
| A target path is shown but the type needs clarification | The path redirects, but the displayed properties alone may not identify every reparse-point implementation. | Run fsutil reparsepoint query and interpret its tag and data. |
| Link fields are empty | This can be consistent with an ordinary directory, but it is not conclusive for every Windows-managed reparse point. | Query the reparse point before declaring the folder a copy. |
Microsoft documents an AppX reparse-point case in which LinkTarget and LinkType are empty. Therefore, a blank field is not proof by itself that the folder is an ordinary copy. Treat the PowerShell output as the first piece of evidence, not an appearance test.
Inspect entries inside a parent folder
When you need to examine several entries rather than one known path, use Get-ChildItem on the parent directory. PowerShell’s filesystem provider can expose target information for links and junctions while listing children. The same caution applies: an empty property can require a lower-level reparse-point check.
Check the exact object, not a similarly named folder
Two folders can have the same name in different locations, and a shortcut or application display can obscure the actual path. Copy the full path from the location you are testing and paste that value into -LiteralPath. Keeping the drive letter and every parent directory in the command prevents you from inspecting a neighboring copy by mistake.
Run the command once for the directory itself. Listing the contents of a parent is a different operation: it can reveal link information for child entries, but it does not automatically classify the parent. If a child behaves like another location, inspect that child as its own filesystem object.
Confirm reparse-point metadata with fsutil
Query the folder
From Command Prompt or PowerShell, run:
fsutil reparsepoint query "C:pathtofolder"Microsoft documents the query operation as retrieving reparse-point data associated with a named file or directory. If the command reports reparse data, the path is not simply an unmarked directory entry. Read the reported tag and data to determine what mechanism is present.
Why a reparse point is not automatically a symbolic link
“Reparse point” is a broad filesystem facility. Windows uses reparse points for directory junctions and volume mount points, and filesystem filters can use them for other purposes. Consequently, fsutil reparsepoint query confirms the presence of special metadata, but the phrase “reparse point” alone does not identify it as a directory symbolic link.
Use the PowerShell link fields and the reparse tag together. If the PowerShell output names a link type and target, it is the most readable description of the object. If it does not, the tag and data from fsutil are the evidence needed to classify the implementation, rather than assuming every reparse point is a symlink.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Use both commands when the first answer is incomplete
The two commands answer related but different questions. PowerShell presents a convenient object-level description, including a target when the filesystem provider exposes one. fsutil examines the lower-level reparse data. Running both against the same quoted path lets you compare a friendly label with the underlying metadata.
Keep the outputs together if you are documenting a problem. Record the full path, the displayed LinkType and target values, and the reparse tag and data. This avoids reducing a nuanced result to the inaccurate statement that “it is a link” when the evidence only establishes a different reparse-point implementation.
Symbolic link, junction, and copy: the practical differences
| Object | What the path represents | Directory support | Typical creation option | How to recognize it while checking |
|---|---|---|---|---|
| Directory symbolic link | A link path that refers to a target directory. | Yes. | mklink /d <link> <target> |
PowerShell may report a symbolic link type and target; reparse data can provide confirmation. |
| Directory junction | A directory redirection implemented as a reparse point. | Yes. | mklink /j <link> <target> |
PowerShell may expose junction information; fsutil confirms and describes the reparse data. |
| Hard link | Another directory entry for the same file record. | No. NTFS hard links cannot reference directories. | mklink /h <link> <target> for a file. |
Check individual files with fsutil hardlink list; the containing directory itself is not a hard link. |
| Ordinary copy | A separate directory tree with its own entries. | Yes. | Not applicable. | No link target is reported; verify with metadata checks rather than visual similarity. |
The mklink syntax explains the categories: /d creates a directory symbolic link, /j creates a directory junction, and /h creates a file hard link. Those switches describe how links are created; they are not a substitute for inspecting an existing folder.
Why the distinction matters
A symbolic link or junction can make software appear to use one directory while actually reading and writing another. That matters when you are troubleshooting storage locations, backups, permissions, or unexpected changes. A copy, by contrast, is a separate tree even when it was made from identical files. Similar names, file counts, or timestamps do not establish that two paths share storage.
Hard links require a separate mental model. Multiple file names can refer to the same NTFS file, so editing one name can affect another. That sharing occurs at the file level; it does not make either containing directory a linked directory and does not turn a collection of hard-linked files into a hard-linked folder.
Check a whole directory tree for junctions
Use Sysinternals Junction with recursive listing
If the question is not only “is this top-level folder a link?” but also “does anything below it contain junctions?”, Microsoft’s Sysinternals Junction utility can scan recursively:
junction -s "C:pathtoparent"The -s option recursively lists junctions beneath the directory supplied. This is a downloadable Sysinternals utility rather than a built-in command. Use it when a large tree may contain hidden redirections that are easy to miss by checking only the parent path.
What a recursive result does and does not prove
A listed junction identifies a redirected directory somewhere below the scanned parent. It does not mean that the parent itself is a junction, and it does not classify every possible reparse-point type. For a particular suspicious path, run the PowerShell and fsutil checks directly as well.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Use the recursive scan as an inventory step. If it reports several descendants, note each path and then inspect the ones relevant to the behavior you are troubleshooting. A scan of a parent cannot replace a direct query when you need the exact target or the precise reparse tag for one child.
Determine whether files inside the folder are hard-linked
A folder can be an ordinary directory while containing files that have hard-linked names elsewhere. NTFS hard links create multiple directory entries that refer to one file. Because hard links cannot point to directories, discovering one does not change the classification of the folder that contains it.
List hard-linked names for a file
Run:
fsutil hardlink list "C:pathtofile"The command lists the paths that are hard links to that file. Use it on a specific file when changes appear in another location and you suspect shared file storage. Do not use a hard-link result to conclude that the directory itself is linked; the command addresses the file’s directory entries.
Choose the file deliberately
Test the file whose changes you can reproduce, using its complete path inside the folder. Checking a random file can miss the one that has another hard-linked name. If the command identifies multiple names, that explains file-level sharing without proving that the parent directory redirects anywhere.
A reliable decision procedure
- Copy the exact folder path. Include the drive and full directory name. Do not rely on Explorer’s appearance or on matching names.
- Run the PowerShell inspection. Use
Get-Item -LiteralPathand formatFullName,Attributes,LinkType,Target, andLinkTarget. - If a type or target appears, record it. You have evidence that the path redirects. A target path tells you where the directory data is being reached.
- If the fields are blank or ambiguous, query reparse data. Run
fsutil reparsepoint queryfor the same path and inspect the returned tag and data. - Classify the result carefully. Call it a symbolic link only when the metadata identifies a symbolic link. Call it a junction when the metadata identifies a junction. Otherwise describe it as a reparse point of the reported type instead of guessing.
- Check below the folder if necessary. Use
junction -sto find junctions in descendants. - Investigate file-level sharing separately. For a suspicious file, use
fsutil hardlink list; this answers a different question from whether the directory is a link. - Treat an unmarked directory as a likely copy, not a visual certainty. If no link metadata is reported and no reparse point is found, the path behaves as an independent directory tree. Keep the AppX caveat in mind when PowerShell properties are empty.
Apply the procedure to one path at a time
Do not mix results from a parent and child. First classify the path named in the original question. If a descendant is the source of the redirection, repeat the commands with that descendant’s exact path. This simple separation prevents a junction found somewhere in a tree from being incorrectly reported as a link at the root.
Troubleshooting unclear or unexpected results
Explorer looks normal
Explorer’s icon, name, and visible contents are not a reliable link test. A symbolic link or junction can look like an ordinary folder, and a copied directory can contain identical files. Always inspect the filesystem object at its path.
PowerShell shows no target
First verify that the command used the folder’s exact path and that Get-Item, rather than a listing of a different parent, was run. If LinkType and LinkTarget remain empty, run fsutil reparsepoint query. Microsoft documents empty link properties for at least one AppX reparse-point scenario, so do not convert an empty field directly into “copy.”
fsutil reports a reparse point but not “symbolic link”
That result is expected when the point is a junction, mount point, or another filesystem-filter mechanism. Reparse-point status is the broad category; use the tag and data, plus PowerShell’s reported type when available, to identify the specific implementation.
A subfolder behaves like another location
Check the subfolder itself with the same two commands. If the parent is ordinary but junction -s lists a descendant, the redirection is below the parent. A recursive result is not evidence that every directory in the tree is linked.
Files change in two directories at once
Check whether the directories are linked, then test the individual file with fsutil hardlink list. A shared file caused by hard links can explain synchronized file changes even when neither containing directory is a hard link.
The target cannot be inferred from appearance
Identical folder sizes, matching timestamps, and the same visible filenames can occur in separate copies. Conversely, a redirected path can display the target’s contents so convincingly that it looks like a normal directory. Metadata, not visual comparison, is the dependable basis for the classification.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What counts as proof of a copy?
Windows does not provide a single appearance-based marker that says “this is a copy.” The useful negative evidence is that the inspected path has no reported link target or link type and that a reparse-point query does not identify special metadata. That combination supports treating the directory as an ordinary, separate tree.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Do not infer independence merely because two folders have different names, similar sizes, or identical timestamps. Those observations can occur with both links and copies. Conversely, do not infer a symbolic link solely because a path redirects: a junction and other reparse-point implementations also redirect or alter filesystem processing.
Use precise wording in documentation
If PowerShell reports a symbolic link and a target, document it as a directory symbolic link and include the target path. If the reparse data identifies a junction, call it a junction. If all you can establish is special reparse metadata without a clear subtype, report the tag and describe it as an unidentified or other reparse point. This wording preserves what the commands actually prove.
Commands at a glance
| Purpose | Command | Scope |
|---|---|---|
| Inspect one folder and display link fields | Get-Item -LiteralPath 'C:pathtofolder' | Format-List FullName,Attributes,LinkType,Target,LinkTarget |
One exact filesystem path. |
| Query reparse metadata | fsutil reparsepoint query "C:pathtofolder" |
One file or directory with reparse data. |
| Find junctions under a directory | junction -s "C:pathtoparent" |
Recursive descendant scan using Sysinternals Junction. |
| List hard-linked names for a file | fsutil hardlink list "C:pathtofile" |
One file; not a directory test. |
Windows versions and command scope
Microsoft’s references for fsutil reparsepoint, fsutil hardlink, and mklink list Windows 10 and Windows 11 applicability. The PowerShell examples use filesystem-object properties documented for PowerShell 7.4’s Get-ChildItem reference. The underlying distinction remains the same: inspect the path, confirm special metadata when needed, and keep directory links separate from file hard links.
Rank #4
The Sysinternals Junction page was last updated September 29, 2022, while Microsoft’s Win32 overview of hard links and junctions was last updated July 8, 2025. Those dates identify the documentation context for the commands; the practical workflow is still to inspect the exact path and verify any ambiguous result with reparse metadata.
Common questions
Frequently Asked Questions
How can I tell immediately whether a folder is a symbolic link?
Run Get-Item -LiteralPath 'C:pathtofolder' | Format-List FullName,Attributes,LinkType,Target,LinkTarget. A populated symbolic-link type and target identify the path as a symbolic link. If the fields are blank or unclear, run fsutil reparsepoint query and interpret the returned metadata.
Does finding a reparse point prove that the folder is a symlink?
No. Reparse points also implement directory junctions, volume mount points, and other filesystem-filter behavior. A reparse query confirms special metadata; the tag, data, and PowerShell link fields are needed to identify the specific type.
Can a Windows directory be a hard link?
No. NTFS hard links apply to files, not directories. A directory can contain files with hard-linked names elsewhere, but the directory itself is not a hard link.
Why are LinkType and LinkTarget empty when the folder still behaves specially?
Microsoft documents an AppX reparse-point case in which those PowerShell properties are empty. Empty fields can be consistent with an ordinary directory, but they are not conclusive for every Windows-managed reparse point. Query the path with fsutil reparsepoint query.
Recommended Free Tools
How do I find junctions anywhere below a folder?
Use Microsoft’s Sysinternals Junction utility with junction -s "C:pathtoparent". The -s option recursively lists junctions beneath the supplied directory. Inspect any reported path separately if you need its exact target or reparse type.
How do I check whether a file inside the folder is hard-linked?
Run fsutil hardlink list "C:pathtofile" for the specific file. The output lists paths that are hard links to that file. This answers a file-level question and does not classify the containing directory.
Can identical folder contents prove that two folders are copies?
No. A redirected directory can show the target’s contents, and an ordinary copy can have identical names, sizes, or timestamps. Use the path’s link fields and reparse metadata instead of visual similarity.
What should I call an item when the commands show reparse metadata but no clear subtype?
Describe it as a reparse point and include the reported tag and data. Do not call it a symbolic link unless the metadata identifies a symbolic link; a junction or another filesystem implementation may be involved.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe Bottom Line
Check the exact directory path with PowerShell first, then use fsutil reparsepoint query whenever the link fields are empty or ambiguous. Treat a reparse point as a broad category, distinguish symbolic links from junctions, and remember that hard links apply only to files. For descendants, scan with junction -s; for file-level sharing, use fsutil hardlink list.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
