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的二进制文件写入磁盘内存？

它是否在某处写入指针或某些内容并在磁盘存储器中声明索引并将超出的二进制文件写入新的内存地址？

这样的问题是我们使用操作系统的原因，它提供了一个抽象层，因此您无需在应用程序级别关注内存如何在硬件级别上存储。

这些层与此类似（对于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时，当你将数据写入流时，几乎永远不会低于Bitstream层（），它会将其交给驱动程序，驱动程序将分割数据，但是下面的下一层需要将数据拆分（4k块）适用于现代硬盘驱动器）。

对于司机如何跟踪“什么去哪里？” 这取决于驱动程序的实现。

要实际回答您的问题，程序附加工作请求比特流文件。一旦它具有比特流，它就将更多数据添加到比特流的末尾。一旦你写入它，操作系统/驱动程序对该比特流的作用是一个黑盒子（你不知道细节），如果你正在处理一个，或者一个FileStream，它将完全不同。关于这种分层结构的好处是你不需要关心！责任是下一层，而该层处理它。MemoryStreamNetworkStream