☰

FileStream 附加操作在物理上是如何工作的？

tag-icon • tag-icon c# windows memory-management io
FileStream 附加操作在物理上是如何工作的？

我正在处理一个前置问题，突然让我思考这个问题......

也许不仅与 FileStream 相关，我想知道我们实际上是如何将二进制文件附加到文件中的。

我想我的问题会引出两个问题：

  1. 硬盘内存是怎样构成的？
  2. 文件如何写入物理内存？

假设我有一个文本文件，包含“ABCDEF”，那么在物理内存中（在硬盘中），内存应该包含字母“ABCDEF”的二进制文件以及文件头二进制文件等（纯文本文件实际上没有头？）....

因此在物理上 6 个字节中将是这样的，顺序取决于处理器类型：

A        B        C        D        E        F
01000001 01000010 01000011 01000100 01000101 01000110

假设我们想在文件中添加字母“G”，那么该文件将包含 7 个字节：

A        B        C        D        E        F        G

01000001 01000010 01000011 01000100 01000101 01000110 01000111

两个文件在磁盘上的物理大小均为 4.00KB。

因为当我们写入字母G时，仍然没有超出4.00KB，所以我们有空间可以写入4.00KB的内存空间。

但是当我们在文件中添加更多内容时，超出 4.00KB 时将使用 8.00KB。

超出4.00KB的二进制文件如何写入磁盘内存？

它是否将指针或某物写入某处并在磁盘内存中声明索引并将多余的二进制文件写入新的内存地址？

答案1

我们使用操作系统就是为了解决这样的问题，它提供了一个抽象层，因此你不需要在应用程序级别关注诸如内存在硬件级别如何存储之类的事情。

这些层与此类似（对于 HDD 驱动器），每个层旁边都显示谁负责该层。

        File (File system)
               |
               v
         Bitstream (OS)
               |
               v
    Sectors (Hardware Driver)
               |
               V
     Bits (Hard disk controller)
               |
               V
Magnetic flux (Hard disk controller)

每一层都不关心其上层或下层在做什么，唯一重要的是它向其上层直接公开已知的 API，并向其下层直接使用已知的 API。

当编写应用程序时，您几乎不会低于比特流层（System.IO.Stream），当您将数据写入流时，它会将其交给驱动程序，驱动程序将拆分数据，但其下一层需要对其进行拆分（现代 HDD 为 4k 块）。

对于驱动程序如何追踪“什么东西去了哪里？”，这取决于驱动程序的实现。

实际上，要回答您的问题，Append 的工作原理是您的程序请求文件的比特流。一旦它有了比特流，它就会将更多数据添加到比特流的末尾。一旦您写入比特流，操作系统/驱动程序对该比特流所做的操作就是一个黑匣子（您不知道细节），如果您使用的是FileStream，MemoryStream或NetworkStream。这种分层结构的优点在于您无需关心！责任是下一层的责任，该层负责处理。

相关内容