☰

获取并理解 NTFS 链接列表

tag-icon • tag-icon symbolic-link hardlink ntfs-junction
获取并理解 NTFS 链接列表

我一直在学习 NTFS 链接（1，2) 并在计算机上玩弄它们。文件名和文件夹名的假名世界很奇怪，我还不清楚我为什么有它们，但可以肯定的是，我有很多。

NTFS 链接要么硬链接或者重新解析点重新解析点要么是连接点，要么是符号链接。

为了更加熟悉它们，我一直尝试生成我的计算机上所有 NTFS 链接的完整列表。

这是一台双驱动器计算机，操作系统位于 C:，数据位于 D:。操作系统是 Windows 10 Pro 64 v 1903（我在此报告的是更新到 v 1909 之前记录的结果）。PowerShell 是默认的 Windows v 5.1。

在下文中，“目录”和“文件夹”这两个术语是同义词。

所有链接

自版本 5.0 以来，PowerShell 显然具有两个未记录的“item”cmdlet 属性：LinkType和target（1，2，3，4）。LinkType 具有价值观“Junction”、“SymbolicLink”和“HardLink”。因此，这应该能够列出我电脑上的所有 NTFS 链接。但是，它不能可靠地工作。特别是，它“用户”文件夹中的某些对象失败。例如，在 PowerShell 中：

PS C:\WINDOWS\system32> echo ("1. " + ("C:\Documents and Settings" | get-item -force).LinkType)
echo ("2. " + ("C:\Program Files\Microsoft Office\root\Client\AppvIsvSubsystems32.dll" | get-item -force).LinkType)
echo ("3. " + ("C:\Program Files\NVIDIA Corporation\NvTelemetry\plugins\NvTelemetry" | get-item -force).LinkType)
echo ("4. " + ("C:\ProgramData\Desktop" | get-item -force).LinkType)
echo ("5. " + ("C:\Users\All Users" | get-item -force).LinkType)
echo ("6. " + ("C:\Users\Default User" | get-item -force).LinkType)
1. 
2. SymbolicLink
3. Junction
4. 
5. 
6.

Windows 命令提示符中的相应结果dir /aL（见下文）是：

1. JUNCTION
2. SYMLINK
3. JUNCTION
4. JUNCTION
5. SYMLINKD
6. JUNCTION

因此看起来，至少对于 PowerShell 5.1 来说，LinkType是不可信任的。

重新解析点

在 PowerShell cmdlet 中get-ChildItem，参数attribute具有属性ReparsePoint。这应该允许识别重新解析点，但不区分连接点和符号链接，因此它不如dir /aL接下来讨论的那么有用。

Windows（命令提示符，不是 PowerShell）命令dir /aL /s X:\ 列出所有重新解析点在目录 X 中。以管理员身份运行，它在数据驱动器上找不到任何文件，在系统驱动器上找不到 574 个文件，大部分在文件夹“Program Files”（而不是“Program Files (x86)”）和“Users”中，在“Program Data”中也有几个，在“Windows”中有一个。

在该命令的输出中dir，目标在对象名称后的方括号中显示，通常包含文件大小或“ <DIR>”的列现在有五个不同的值：0（可能是文件大小）、通常的<DIR>，以及三个新值：<JUNCTION>，<SYMLINK>，<SYMLINKD>。在我的计算机上，仅在系统驱动器上，这些值出现的频率以及链接和目标对象的特征如下：

 Count   Type/Size    Link object        Target object
   11    <JUNCTION>   Folder with root   Folder with root
   36                 Folder not found   Folder with root
    9                 Folder not found   Folder w/o root
    7                 Folder not found   Folder not found
   10    <SYMLINK>    dll file           dll file
    1    <SYMLINKD>   Folder w/o root    Folder w/o root
  488    <DIR>        Folder with root   None
   12    0            exe file           None
 ----
  574    Total

在该表中，对象类型具有以下含义：（在此项目列表中，dir表示dir以管理员身份在命令提示符（不是 PowerShell）中以无参数（具体来说，没有参数/aL）运行对象。）

  • 带根的文件夹：dir产生一个看起来像常规目录列表的列表，以<DIR> .代表对象（目录）本身开头。
    • 示例（目标对象）：dir "C:\Users\Public\Documents"
  • 无根文件夹：dir生成一个或多个不以<DIR> .对象本身的名称或名称开头的对象的列表。
    • 示例（目标对象）：dir "C:\Users\Public\Desktop"
  • 未找到文件夹：dir显示“未找到文件”，并且对象名称看起来不像带扩展名的文件名。（在 PowerShell 中，dir显示“拒绝访问...”。）
    • 示例（链接对象）：dir "C:\Documents and Settings"
  • 文件：dir生成一个项目的列表，它是对象本身的名称。
    • 示例（链接对象）：dir "C:\Program Files\Microsoft Office\root\Office16\C2R64.dll"

显然，<JUNCTION>表示连接点，而<SYMLINK>和<SYMLINKD>表示文件和文件夹的符号链接。但我对这里的其他信息有疑问：

  • 那些 500 个对象被dir /aL称为重解析点，但被标记为<DIR>或文件大小为零，并且没有目标，它们是什么？这些<DIR>对象是连接点、符号链接还是其他东西？这些零大小文件是符号链接还是其他东西？如果它们是链接，它们链接到什么？
  • 不以<DIR> .(“Folder w/o root”) 开头的目录列表是什么？我以前从未见过。
  • 为什么有些连接点及其目标可以通过dir（无需/aL）找到，而其他的却不能？

硬链接

似乎没有一种简单、原生的方式来获取硬链接列表。以下是我迄今为止在 Stack Exchange 上找到的有关此主题的六个答案：

我还没有测试完所有方法。有什么建议可以有效地进行这条调查，以获得所有硬链接的正确列表？

概括

  • 关于所有链接LinkType：对于我的发现，您认为不能信任我正确报告所有 NTFS 链接，您有何评论？
  • 关于重新解析点：对该部分末尾提出的三个问题有任何答案吗？
  • 关于硬链接：对于获得好的列表有什么建议吗？
  • 关于这个奇怪的文件系统假名世界，还有其他智慧或见解可以分享吗？

答案1

关于硬链接：对于获取好的列表有什么建议吗？

我怀疑硬链接一旦创建，是否会显示为不同的 LinkType，因为它们的工作方式是让多个名称（目录条目）指向同一个文件对象与原名相同。

确定文件的唯一方法有hardlinks 的作用是检查其“链接数”，就像fsutil您找到的脚本一样。同样，在 Linux 上，POSIX stat() 具有“nlink”属性，可告诉您文件所含的链接数（这是在 中显示的数字ls -l）。

然而，NTFS 中几乎没有什么可以让你区分硬链接，大多数 Unix 文件系统中也没有。从原始文件。您只能判断两个文件是硬链接的，因为它们指向相同的“inode”（嗯，相当于 NTFS），但您不知道后来添加了哪个链接：它只是一个具有两个名称的文件。

NTFS 链接是硬链接或重新解析点，而重新解析点是连接点或符号链接

[...]

dir /aL 表示的 500 个对象是重新解析点，但被标记为或为零文件大小，并且没有目标，这 500 个对象是什么？这些<DIR>对象是连接点、符号链接还是其他什么？这些零大小文件是符号链接还是其他什么？如果它们是链接，它们链接到什么？

并非所有重新解析点都是链接。它们可以包含各种标签，其一般用途只是将文件查找重定向到某个驱动程序。

  • 例如，Windows 允许将驱动器/卷挂载到空文件夹（Unix 样式），而不是为其指定“驱动器号”。然而，与瞬时挂载点不同的是，Windows 挂载点在文件系统中是持久的 - 它们是一种存储已挂载卷 ID 的重新解析点。

  • 重新解析点的另一个非常常见的用途是实现“云”或“仅在线”文件，如 OneDrive 和 Dropbox（它们的实现方式也非常不同） - 它们显示为常规文件，一旦打开就会触发在线下载。

如果你正在使用以某种方式安装的 Microsoft Office（不完全确定，但我思考（如果您使用的是通过 ClickOnce 安装的 Office 365，则似乎使用了另一种类型的重新解析点，这些重新解析点既不是连接点也不是符号链接。使用fsutil reparsepoint query这个来查看是否能找到有趣的东西。

未找到文件夹：dir 输出“未找到文件”，并且对象的名称看起来不像带有扩展名的文件名。（在 PowerShell 中，dir 输出“拒绝访问...”。）

示例（链接对象）：dir "C:\Documents and Settings"

不幸的是，“未找到文件”也是 CMD 报告由于安全限制导致的错误的方式——这并不意味着它成功检索到了一个空列表。

“Documents and Settings” 是一个标准连接点，它只有一个 ACL（参见icacls），明确拒绝列出其内容。blogs.msdn.com 上有一篇旧帖子说，这样做是为了避免某些忽略链接的程序扫描相同的用户配置文件目录两次。

相关内容