问题标签 [ntfs-mft]

我有一个第三方应用程序安装程序，它在文件夹 C:\WINDOWS\system32\drivers 中安装一个 sys 文件。我想最终以编程方式获取它放置在文件系统上的实际日期，以便我可以编写一个工具来显示在安装操作系统后添加的驱动程序文件。

不幸的是，Windows 资源管理器中显示的 sys 文件的创建日期时间戳是过去的，并且不能正确显示文件放置在文件系统上的日期（它是几年前）。到目前为止，我还不知道如何将文件放在具有过去创建日期的文件系统上。不过，我希望 GetFileTime 返回相同的信息。

如何获取文件添加到 (NTFS) 文件系统的实际日期？这甚至可能吗？

我已经查看了如何获取将文件放置在 Windows 上的目录中的日期/时间？但这无济于事。

我需要一种简单、轻量级的方法来读取 Windows 服务器上的 NTFS MFT，仅使用 C。我的目标是以编程方式为我的公司正在构建的应用程序返回一组目录及其权限。

我在 StackOverflow 和其他地方研究过的所有其他答案都涉及使用 C++ 或其他语言，并且通常非常臃肿。我很确定只需几行代码就可以完成我想要的工作，使用 Windows API 调用 CreateFile（获取根卷的句柄）和 DeviceIoControl（读取 MFT）。但我找不到一个简单的 C 解决方案来做到这一点。

请注意，尽管我多年来一直是 C#/.NET 开发人员（并且还了解其他语言，包括 Java 和 Python），但我对低级 C 编程和 Windows API 调用还是相当陌生。我也意识到也有一个免费的 Mft2Csv 可以做到这一点。但是我无法使用实际的源代码进行逆向工程（GitHub 只有可执行文件和支持文件）。

我还意识到我可以使用 C# .NET 命名空间 System.IO 和 System.Security.AccessControl 来解析目录树。但这对于我的目的来说太慢了。

.NET 平台的 DirectorySecurity 命名空间中的方法（例如 GetAccessRules()）对于我的目的来说太慢了。相反，我希望直接查询 NTFS $Secure 元文件（或者，$SDS 流），以便检索每个文件系统对象的本地帐户列表及其相关权限。

我的计划是首先读取 $MFT 元文件（我已经知道如何去做） - 然后，对于其中的每个条目，在元文件（或流）中查找适当的安全描述符。

理想的代码块如下所示：

我希望我的输出看起来像这样：

我在 Windows 10 上运行 .NET 版本 4.7.1。

我正在阅读 NTFS 文件系统的 MFT 条目。

我知道 MFT 可以有多个 FileName 属性，这些属性是在我们创建硬链接时创建的。我知道可以为目录创建连接/符号链接。连接点/符号链接是使用重解析点实现的。

在读取使用 NTFS 文件系统格式化的 VHD 文件时，我发现“目录”的一些 MFT 条目具有多个文件名属性和单个重解析点。

目录是否有可能具有硬链接（并且不止一个？）。以下是实际的 MFT 记录。和截图。我们如何使用 mklink 工具在 MFT 中创建这样的记录？

我有一些代码正在解析 NTFS 磁盘上的 $MFT。

一切正常，除了少数记录（大约 60000 条中的 10 条）在文件名中返回不正确的字符。请看下面的截图：

请注意由字节“0E”定义的 Unicode 字符。在所有其他应用程序中，这是一个下划线字符。见下文：

即使在包含目录的 $INDEX_ROOT 属性中，它也具有正确的名称：

我读错了 $FILE_NAME 属性吗？还是我应该忽略那里的内容并始终使用目录的 $INDEX_ROOT 属性中的名称？这似乎有点倒退？

注意：它并不总是“0E”，也不总是这个文件名，但似乎总是只有一个字符在每个“坏”记录中都是错误的。

我正在尝试解析 MFT 记录中的数据运行，并将结果与​​活动磁盘编辑器进行比较。数据运行如下：

.... 4 2 0F 01 FD 83 90 D9 0C（第二个属性从这里开始）

如果我理解正确：这就是它应该被解析的方式：

• 解析簇数的字节数：2

• 解析簇位置的字节数：4

• 解析簇数：0F 01（小端）=> 271

• 解析第一个集群位置：0x D99083FD => 3,650,126,845
• 期望 00 而不是 0C 来标记集群的结束

但是，在活动磁盘编辑器中：

• 集群位置是：9,470,973，即0x 9083FD。（D9 被忽略）。事实证明，这个位置是正确的。

• 如果我尝试更改表示群集位置的字节数（4中的4 2），会发生以下情况：

  • 如果我将其更改为 4 或 5，则群集位置保持不变 (9470973)
  • 如果我将其更改为 3，则群集位置变为负数
  • D9 0C 上的值没有变化似乎会影响结果

谁能让我知道我做错了什么？

我在用着：

枚举计算机的所有 NTFS 分区。

它适用于我的 Windows 7、我尝试过的 Windows 8.1 以及 Windows 10 计算机。

但它在另一台 Windows 10 计算机上失败：在这台计算机上，卷C:的diskInfo.PartitionType值等于0x00，而不是0x07( PARTITION_IFS)。

该值是（请参阅此处的文档）：

PARTITION_ENTRY_UNUSED：0x00：未使用的条目分区。

这很奇怪，因为我可以确认，分区确实是 NTFS。

问题：

• 众所周知，IOCTL_DISK_GET_PARTITION_INFO获取分区类型不是 100% 可靠吗？

• 枚举所有 NTFS 卷的更可靠方法是什么？

注意：我还查看了 usingIOCTL_DISK_GET_PARTITION_INFO_EX而不是，IOCTL_DISK_GET_PARTITION_INFO但是结构PARTITION_INFORMATION_EX似乎没有提供有关的信息PartitionType，而结构PARTITION_INFORMATION确实提供了对PartitionType.

我很好奇恢复软件如何打开主文件表。就像他们做api调用一样？

我正在研究文件虚拟化和版本控制项目。为此，我需要直接访问文件内容的逻辑块，而不需要复制到内存中。任何人都可以帮助我处理适用于我的 64 位 Windows 的代码片段吗？

我尝试了以下代码来访问 MFT 文件。但即使我以管理员权限运行，它也会像“拒绝访问”一样响应。

谢谢

请在引用“转发”之前阅读 - 我知道有人问过类似的问题，但我还没有找到满意的答案

我的目标是提供一个树状的磁盘空间使用目录结构，允许用户向下钻取层次结构以找到相当大的文件夹。

TreeSize 程序就是一个很好的例子，我希望得到与这个程序相同的响应时间。

我当前的代码可以使用 MFT 在大约 25 秒内遍历我的 480GB 文件。我从这一点开始通过获取文件信息来构建目录大小（MFT 只包含文件名和 parentId，而不是完整的文件路径）

要从 MFT 日记条目中获取文件信息，我当前的代码调用

不幸的是，这段代码将程序的整体执行时间从 25 秒增加到 5 分钟。

有没有更好的方法来获取文件信息？

非常感谢您建议 FindFirstFile 和 FindNextFile 但是对于处理大目录，这些选项太慢了

代码如下（我不是你可能注意到的 C 程序员！）

非常感谢