Powershell: No Target property of Hard links

[xa0082249956]

Steps to reproduce

Get-Item (Join-Path $env:SystemRoot explorer.exe) | % Target

Expected behavior

C:\Windows\WinSxS\amd64_microsoft-windows-explorer_<xxxxxxxx>\explorer.exe

Actual behavior

(no output)

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-rc.2
PSEdition                      Core
GitCommitId                    7.0.0-rc.2
OS                             Microsoft Windows 10.0.19564
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[NoMoreFood]

Hard links really don't have targets. When you create a hard link (using something like mklink /h), you're really just passing in "target" file as a means to identity the underlying data on the file system to create a new named pointer to. By definition, every named file has one hard link and you can have any number of hard links for a specific piece of data on the file system. Junctions and symbolic links are a different story -- they have specific targets.

[xa0082249956]

Thanks. I tried to make another hard link and found that there is no Target property too.
However, I don't know why Windows PowerShell have the target property. Maybe because of some difference between .NET and .NET Core?

[NoMoreFood]

Windows PowerShell takes a sensible approach: it will return an array of hard links that are not the same as the file being queried. So let's say I create two hard links called 'A' and 'B' that using 'C' as a reference. In Windows PowerShell, I look at the Target property for 'A', I get an array of @('B','C'); if I look at 'B', I get an array of @('A','C'); if I look at 'C', I get an array of @('A','B').

Looking at the file system provider in PowerShell Core, I do not see any effort to enumerate hard links. My guess is that this is due the desire to maintain feature parity between Linux and Windows. Linux does not have a great way to query all hard links associated with a file (i.e. you have to enumerate every file on physical volume to see if a file points to the same physical location).

[xa0082249956]

Thanks for your explanation! So I think the issue can be closed now.