.net - System.IO.FileInfo的 “Target”成员在哪里记录？

Question

PowerShell Commandlet Get-Item(如果应用于文件)将返回System.IO.FileInfo类型:

PS C:\> $item = get-item c:\windows\System32\atl.dll
PS C:\> $item.GetType().FullName
System.IO.FileInfo

使用 $item上的制表符，我发现它具有一个名为 Target的成员/属性:

PS C:\> $item.Target
C:\Windows\WinSxS\amd64_microsoft-windows-atl_31bf3856ad364e35_10.0.18362.1_none_7d7dafc1d6eadbc7\atl.dll

但是，Microsoft的文档中没有提及该成员/属性。
System.IO.FileInfo
及其基类 System.IO.FileSystemInfo。

我怀疑 Target的值在某种程度上是结点，符号链接(symbolic link)或硬链接(hard link)指向的位置-但是，如果我在目标文件上应用 Target，则会再次获得原始文件:

PS C:\> (get-item $item.Target).Target
C:\Windows\System32\atl.dll

那么，这个 Target成员是什么？

Answer 1

tl;博士:

没有ETS(扩展类型系统)成员的文档，例如.Target。

c:\windows\System32\atl.dll是指向相同文件数据的两个所谓的hard links之一(另一个是C:\Windows\WinSxS\amd64_microsoft-windows-atl_31bf3856ad364e35_10.0.18362.1_none_7d7dafc1d6eadbc7\atl.dll)。

对于硬链接(hard link)，.Target报告所有其他硬链接(hard link)(指向同一文件的路径)，这就是为什么两个项目的.Target属性值指向各自其他路径的原因。

您的代码不再在PowerShell [Core]中工作，在PowerShell [Core]中，不再支持通过.Target报告硬链接(hard link)-请参见this GitHub issue。

正如Mathias R. Jessen所指出的那样， .Target 属性是 ETS (Extended Type System)属性-PowerShell为扩展本机.NET类型的功能而添加的属性。

对于此类ETS成员(可能还包括方法)，没有 没有任何文档-您的最好的选择是研究其定义，但不能保证为您提供完整的故事或仅付出不小的努力即可:

第一步，您可以使用 Get-TypeData cmdlet来检查.Target属性的定义(已添加到System.IO.FileInfo和System.IO.DirectoryInfo实例中):

# Windows PowerShell
PS> (Get-TypeData System.IO.FileInfo).Members.Target | foreach GetCodeReference

Name                       : GetTarget
DeclaringType              : Microsoft.PowerShell.Commands.InternalSymbolicLinkLinkCodeMethods
[...]
MemberType                 : Method
ReturnType                 : System.Collections.Generic.IEnumerable`1[System.String]
[...]

(Get-Item $PROFILE | Get-Member Target也可以使用，但是在这种情况下缺少重要信息:.Target属性的类型为CodeProperty，即，其值由对.NET类型的静态方法的调用确定的属性，但是输出的.Definition属性显示方法仅作为Target{get=GetTarget;}；即，缺少完整的类型名称)。

也就是说，使用手头的[Microsoft.PowerShell.Commands.InternalSymbolicLinkLinkCodeMethods]::GetTarget()实例调用System.IO.DirectoryInfo可以返回该实例的.Target属性值。

在Windows PowerShell中，这是该行的结尾，因为其源代码不可公开使用。

在PowerShell [Core] 6+中，您可以检查GitHub repository中的源代码，尤其是文件 FileSystemProvider.cs 中的源代码(此链接是一个永久链接，随着时间的推移，它将变得过时；请单击页面顶部的Branch:下拉列表以切换到当前的master分支)。

接下来讨论.Target的部分推断的行为。
.Target的目的和行为:

.Target属性返回文件系统解析点(Windows)/ symlink(符号链接(symbolic link)； Unix)目标路径。[1]

如果输入路径不是重新解析点或符号链接(symbolic link)，则.Target返回“nothing”:具体来说，[System.Management.Automation.Internal.AutomationNull]::Value(Windows PowerShell；在大多数情况下，其行为类似于$null)/ $null(PowerShell [Core])。

Windows PowerShell和PowerShell [Core] 6+(从PowerShell 7.0开始)之间.Target的行为存在重要差异:

在Windows PowerShell中，.Target返回目标路径的枚举，这意味着可以返回多个路径，仅当输入路径是同一文件(数据)的多个hard links之一时，该路径才适用。

具体来说，硬链接(hard link)的.Target属性报告存在于该文件的所有其他硬链接(hard link)(即，不包括输入路径)。

这说明了为什么在给定具有两个硬链接(hard link)的文件时，为什么它们的.Target属性指向相应的其他路径，例如由硬链接(hard link)C:\Windows\System32\atl.dll指向的文件就是这种情况。

在PowerShell [Core]中，.Target仅每个返回一个路径，因为已删除了对硬链接(hard link)的支持-请参阅this GitHub issue。

旁白:与Windows不同，类Unix平台不支持枚举硬链接(hard link)的系统级支持，因此查找到给定文件的所有硬链接(hard link)既麻烦又缓慢。

[1]除了hard links之外，类Unix平台仅包含symbolic links，而在Windows上，reparse points的类别不仅包括符号链接(symbolic link)，还包括结点，卷安装点，以及在最近的Windows版本中，AppX重解析点(应用执行别名)适用于Microsoft Store应用程序)。