Get-Item -LiteralPath: final links versus intermediate reparse points in PowerShell 7.5

Question

Get-Item -LiteralPath: final links versus intermediate reparse points in PowerShell 7.5

Manica Moscon Advogados 0

I am reviewing a hypothetical Windows FileSystem-provider metadata query using Get-Item -LiteralPath. The documentary baseline is PowerShell v7.5.0, commit 713e77f15f63bae9f23fb02045c7843ad6a8769b. This is not a report of an installed or tested runtime.

The FileSystem provider documentation describes link-related properties, but those properties alone do not establish which filesystem accesses occurred.

Could you clarify these two cases?

Final component: When the named item is a symbolic link, junction, or another reparse-point type, does Get-Item return the link’s metadata, the target’s metadata, or a mixture? Can obtaining that object implicitly access or follow the target? Please identify the types covered.

Intermediate components: For a hypothetical path such as C:\example\parent\item, where parent redirects through a reparse point but item is ordinary, how are the intermediate components resolved? Does the documented behavior cover actual path resolution, or only representation of the final item?

Please provide one primary, versioned source—either an applicable public contract or implementation evidence—with a direct URL and relevant passage. For implementation evidence, please identify the actual repository path in the commit above and distinguish FileSystem-provider behavior from work delegated to System.IO or Windows.

A partial answer covering one case, with explicit version/platform/type limits and the remaining boundary, would be useful. I am not inferring no-follow from LiteralPath or transferring Get-ChildItem/FollowSymlink behavior to Get-Item. No machine tests or universal zero-I/O guarantee are requested.

Manica Moscon Advogados 0 Reputation points

2026-10-27T17:35:42.7233333+00:00

Thank you. We have checked two Windows rules: an absolute intermediate symbolic link can replace the path prefix through the link with a UNC destination while preserving the remaining suffix; GetFileAttributesW returns the symbolic link’s attributes when the path points to it. These rules do not identify the operations performed by Get-Item -LiteralPath.

The documentary baseline remains PowerShell v7.5.0, commit 713e77f15f63bae9f23fb02045c7843ad6a8769b, not an installed or tested environment. Could you provide one primary, versioned source with a direct URL and relevant passage: either an applicable Get-Item contract or implementation evidence connecting the FileSystem provider’s literal input to the managed metadata operations and Windows APIs actually used?

The earlier source link uses master. If relying on implementation, please identify the actual repository path and a permalink pinned to the commit above. Please distinguish what the provider establishes from behavior delegated to System.IO or Windows. The .NET 10 LinkTarget/ResolveLinkTarget documentation does not by itself identify the runtime binding for this baseline; please state the applicable runtime/version.

If evidence covers only the final-component case or only intermediate components, that partial answer is useful. Please state the link/reparse-point types covered and the remaining boundary; a complete audit of all transitive code is not requested. No machine tests or universal zero-I/O guarantee are requested.

2 answers

Your answer

Manica Moscon Advogados 0 Reputation points

2026-10-27T17:35:42.7233333+00:00

Thank you. We have checked two Windows rules: an absolute intermediate symbolic link can replace the path prefix through the link with a UNC destination while preserving the remaining suffix; GetFileAttributesW returns the symbolic link’s attributes when the path points to it. These rules do not identify the operations performed by Get-Item -LiteralPath.

The documentary baseline remains PowerShell v7.5.0, commit 713e77f15f63bae9f23fb02045c7843ad6a8769b, not an installed or tested environment. Could you provide one primary, versioned source with a direct URL and relevant passage: either an applicable Get-Item contract or implementation evidence connecting the FileSystem provider’s literal input to the managed metadata operations and Windows APIs actually used?

The earlier source link uses master. If relying on implementation, please identify the actual repository path and a permalink pinned to the commit above. Please distinguish what the provider establishes from behavior delegated to System.IO or Windows. The .NET 10 LinkTarget/ResolveLinkTarget documentation does not by itself identify the runtime binding for this baseline; please state the applicable runtime/version.

If evidence covers only the final-component case or only intermediate components, that partial answer is useful. Please state the link/reparse-point types covered and the remaining boundary; a complete audit of all transitive code is not requested. No machine tests or universal zero-I/O guarantee are requested.

Answer 1

Ronald Sabiiti 1,585 Independent Advisor

Hello Manica,

In PowerShell 7.5.0, Get-Item -LiteralPath returns a FileInfo or DirectoryInfo object. Although link-related properties are available for supported reparse-point types, they do not guarantee that only the link’s metadata is accessed or that the target is never followed.

For intermediate path components, such as a junction or directory symbolic link in C:\example\parent\item, normal Windows path resolution can follow the link to locate the final item. Using -LiteralPath does not prevent this.

The provider’s implementation helps explain how the metadata object is created, but it does not establish a universal no-follow guarantee for every reparse-point type or filesystem operation.

For reference:

PowerShell 7.5.0 FileSystemProvider.cs — source at the specified commit

FileSystem provider documentation — PowerShell 7.5

I hope this clarifies the distinction. The key point is that the returned metadata and the filesystem operations used to resolve the path are separate considerations.

If this information was helpful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Manica Moscon Advogados 0 Reputation points

2026-10-27T18:15:19.8666667+00:00

Thank you. The commit-pinned file helps establish the source context, but I still need a precise locator for the GetItem definition rather than the class-level OutputType annotations.

Could you provide a GitHub permalink selecting the definition’s start and end source lines at commit 713e77f15f63bae9f23fb02045c7843ad6a8769b? I am looking for the method signature and its opening/closing boundaries, not GetItemDynamicParameters or a call site. If the definition is in another partial-class file, please identify that file in the same commit.

Alternatively, a short excerpt identifying the signature and boundaries would be enough; there is no need to reproduce the entire function or follow its helpers.

This remains a documentary review of the PowerShell v7.5.0 baseline, not a report of an installed or tested environment.
Ronald Sabiiti 1,585 Reputation points Independent Advisor

2026-10-27T18:42:50.9+00:00

Hello Manica,

I’m sorry I haven’t yet verified the exact GetItem method boundaries. I understand the importance of an accurate, commit-pinned reference.

As a next step, I’ll verify the method’s location in the specified commit and provide a direct link to the correct lines.

Thank you for your patience and understanding.

Answer 2

For PowerShell 7.5 on Windows, Get-Item -LiteralPath represents a final linked item as a FileInfo or DirectoryInfo for the link path, but intermediate symbolic-link components are resolved by Windows as part of pathname lookup; the available sources do not establish a universal “target is never accessed” guarantee or the exact provider call path at commit 713e77f15f63bae9f23fb02045c7843ad6a8769b.

Final path component

The PowerShell 7.5 FileSystem-provider contract says:

Files are returned as System.IO.FileInfo.
Directories are returned as System.IO.DirectoryInfo.
For a linked item, Mode contains l, and LinkType identifies the link type.
On Windows NTFS, possible LinkType values include HardLink, SymLink, Junction, and other values.
AppExecLink is an explicit exception: Windows supplies neither LinkType nor LinkTarget for it. ^1^

That establishes representation of the final named item, not a complete trace of filesystem operations. In particular:

LinkTarget describes “the target path of the link located in FullName”; it does not replace the returned object with an object representing the target. Its documented resolution scope is symbolic links and junctions. ^2^
Explicit target resolution is a separate operation, ResolveLinkTarget(bool). Passing false returns the immediate target and true follows links to the final target. That API is documented for symbolic links and junctions. ^3^

Therefore, for symbolic links and junctions, the supported conclusion is:

The returned object represents the item at the supplied link path.
Link-specific properties describe that link.
It is not equivalent to an explicit ResolveLinkTarget(true) operation.
This does not imply zero target-related I/O. Property evaluation, filesystem filters, and reparse processing can cause additional access.

For Windows symbolic links specifically, Windows documents that GetFileAttributes and GetFileAttributesEx return attributes for the symbolic link rather than its target. It also documents that find operations return link information, while other APIs can use the target; consequently, an object’s properties should not be generalized into a single “all metadata is link metadata” rule without identifying each underlying API. ^4^

For other reparse-point types, no universal answer follows. Reparse data can be interpreted by a filesystem filter, and that filter may redirect, retrieve, or otherwise process the item. If the corresponding filter is unavailable, opening the item can fail. ^5^ Thus, the symbolic-link/junction conclusions must not be extended to AppExecLink, cloud placeholders, HSM, mount points, or arbitrary third-party tags without a type-specific contract.

Intermediate path components

For a path such as:

Get-Item -LiteralPath 'C:\example\parent\item'

if parent is a Windows symbolic link, Windows pathname resolution replaces that component with its target and appends the remaining item suffix. Microsoft’s absolute-link example changes:

C:\alpha\beta\absLink\gamma\file

into:

\\machineB\share\gamma\file

when absLink targets \\machineB\share. Relative links are handled similarly, followed by normalization of .. components. ^6^

Accordingly, if parent redirects to C:\target, lookup of the ordinary final component proceeds logically as C:\target\item. The returned object represents item, not parent. This is Windows path resolution, not the PowerShell Extended Type System’s representation of a final linked item.

The PowerShell provider documentation describes the objects and link properties exposed by Get-Item; it does not specify the component-by-component Windows name-resolution algorithm. -LiteralPath prevents PowerShell wildcard interpretation—it should not be treated as a no-follow filesystem-open flag.

Source-level boundary

The repository path for the provider is:

src/System.Management.Automation/namespaces/FileSystemProvider.cs

The available repository source identifies this as the FileSystem-provider implementation location. ^7^

However, that URL points to master, not commit 713e77f15f63bae9f23fb02045c7843ad6a8769b. The supplied material does not contain a commit-pinned listing with the relevant GetItem symbols and calls. It therefore cannot substantiate an exact claim about whether that revision constructs FileInfo/DirectoryInfo, requests attributes, evaluates LinkTarget, or invokes another System.IO helper at a particular line.

The defensible boundary is:

PowerShell 7.5 contract: final linked items are exposed as FileInfo/DirectoryInfo objects with link metadata.
System.IO contract: LinkTarget and ResolveLinkTarget have explicit symbolic-link/junction semantics.
Windows contract: intermediate symbolic-link components rewrite the path, while final-component behavior varies by the filesystem API and reparse type.
Not established here: the exact provider-to-System.IO call chain at the requested PowerShell commit or a universal zero-target-I/O guarantee.

References