使用 Win NT 内核 API 连接大文件答案

【问题标题】：Concatenate large files using Win NT kernel API使用 Win NT 内核 API 连接大文件
【发布时间】：2014-01-03 12:39:25
【问题描述】：

我一直在寻找一种将大文件（几 GB）连接在一起而不必重写其中一个文件的方法。我确信操作系统在操作主文件表时会在内部执行此操作。这纯粹是针对速度至关重要的内部应用程序，即使以数据完整性为代价（如果冒着未记录的 API 的风险）。该应用程序处理大量高带宽、多通道以太网数据，其中损坏的工作单元（在本例中为文件）不会对整体处理结果产生很大影响。

在合并文件A 和B 时，所涉及的工作量等于：A[Read] + B[Read] +C[Write]`。你们中的任何一位 NT 专家能否阐明如何解决这个问题以直接进入 MFT？

我无法获得关于要探索哪个 API 的任何线索，希望能得到一些建议。尽管该应用处于托管状态，但我很乐意探索原生 API，甚至设置轻量级 VM 进行测试。

提前致谢。

【问题讨论】：

您的建议在许多要求属于文件的每个集群都是连续数据（最后一个除外）的文件系统中是不可能的。
打开A，将文件指针设置到文件末尾，写入B的内容。破解MFT没有意义。在此过程中丢失 A，尤其是在出错时，通常不会被认为是非常可接受的。

标签： c# .net windows-kernel windows-nt nt-native-api

【解决方案1】：

如果您要将文件 B 附加到文件 A，您所要做的就是打开文件 A 以 write+append ，寻找文件末尾，然后从 B 读取并写入 A。

如果你想创建文件 C 作为文件 A 和文件 B 的连接，那么你将不得不创建文件 C 并将 A 复制到 C，然后将 B 复制到 C。

没有任何快捷方式。

【讨论】：

【解决方案2】：

这不是文件系统真正会做的事情。文件系统根据簇和数据块为文件分配空间，而不是字节。像这样连接两个文件只有在它们都是集群大小的倍数时才有效，并且 FS 可能对如何将块分配给幕后文件有其他假设。如果您卸载文件系统并编写一个工具来直接操作所有文件系统结构，您也许可以自己对文件系统执行此操作。但如果这样做，您将面临损坏整个磁盘的风险，而不仅仅是单个文件。

【讨论】：

【解决方案3】：

我不知道您的确切情况，但是否可以根本不将文件附加在一起？只要在接收数据时不断将文件扔到某个目录中，并保留一个索引

那么当需要数据时，使用索引将数据拼凑起来创建一个新文件？所以你只做昂贵的文件按需合并？

【讨论】：