【问题标题】:When using Filestream Filemode.Append does it overwrite what is lying next to the file?使用 Filestream Filemode.Append 时,它会覆盖文件旁边的内容吗?
【发布时间】:2022-01-21 06:17:56
【问题描述】:

假设在 File-1-EOF 之后正好 1 个字节另一个文件 (file2) 开始。

如果我打开文件 1 并使用 FileStream Filemode.Append,它会覆盖 file2 还是在有足够内存的地方制作另一个副本?

谢谢,问候!

编辑: 对于我之后的每个人:我忘记了你有一个文件系统,它被分成了块。让这个问题变得无稽之谈!

【问题讨论】:

  • 我想当您在特定文件路径上使用 FileStream 时,只会修改该文件。如果不是,那似乎对它的使用非常不利。
  • 是的,但是如果你编辑它最后有更多字节呢?您必须复制或覆盖(这很糟糕)
  • 这取决于分区上的文件系统。这不像 c/c++ RAM 访问,超过内存限制会导致其他信息。文件系统不是这样工作的,虽然你可以拥有这种能力,如果你想要的话,FileStream 在进行修改时肯定不会损坏其他文件。
  • 如果使用普通的 c# 函数可以做到这一点,它会破坏您的文件系统并损坏您的磁盘。 Filestream 和磁盘扇区之间有多个 API。
  • 对于我之后的每个人:我忘记了你有一个文件系统,它被分成了块。让这个问题变得无稽之谈!

标签: c# append overflow filestream overwrite


【解决方案1】:

您似乎误以为文件是按顺序存储在磁盘上的,并且扩展一个文件可能会覆盖另一个文件的部分内容。当您通过 c# 中的文件流追加时,不会发生这种情况。操作系统将写入您添加的字节,无论它喜欢,无论它喜欢什么(并且它喜欢不覆盖其他文件),这就是文件最终被分解成分散在磁盘上的更小的块(以及为什么要进行碎片整理)的方式。这些都与您无关,因为操作系统将这些分散的文件片段作为单个连续的字节流呈现给任何想要读取它们的程序

当然,如果你编写了一个绕过操作系统并执行低级别磁盘访问的程序,定位到文件的末尾,然后盲目地将更多字节写入其后的位置,那么你最终会损坏其他文件,甚至操作系统精心策划的文件系统 .. 但 .net 文件流无法实现这一点

TLDR;添加你的字节,不要担心。保持文件系统井井有条不是你的工作

【讨论】:

    【解决方案2】:

    如果我打开文件 1 并使用 FileStream Filemode.Append,它会覆盖 file2 还是在有足够内存的地方制作另一个副本?

    谢天谢地没有。

    以下是原因的简要概述:

    您的 .NET C# 代码没有直接的操作系统级交互。

    您的代码被编译成字节码,并在运行时由 .NET 运行时进行解释。

    在运行时,您的字节码由 .NET 运行时执行,该运行时主要由 C#/C/C++ 组合而成。

    运行时保护它所谓的 SafeHandles,它们是文件句柄的包装器,我可以假设是 window.h(至少对于 WIN32 应用程序),或者文件的任何操作系统级别提供程序处理您正在运行的架构。

    运行时使用这些句柄通过操作系统级 API 读取和写入数据。

    操作系统的工作是使用它提供给运行时的句柄来确保对yourfile.txt 的更改仅影响该文件。

    文件通常不存储在内存中,因此不会受到缓冲区溢出的影响。

    运行时可能使用内存中的缓冲区来..缓冲您的读取和写入,但这是由运行时实现的,对文件和操作系统没有影响。

    任何溢出此缓冲区的尝试都会受到运行时本身的保护,并且您的代码的执行将停止。无论如何,如果此缓冲区成功发生缓冲区溢出 - 不会将额外的字节写入底层句柄。相反,运行时可能会因内存访问冲突或一般未指定行为而停止执行。

    您获得的句柄只不过是操作系统用来跟踪您要读取或写入字节的文件的令牌。

    如果您尝试向文件写入的字节数超出架构允许的范围 - 大多数操作系统都会设置安全防护措施来结束您的进程、关闭文件或直接发送中断以使系统崩溃。

    【讨论】:

    • 您提到的很多内容并不直接相关:操作系统并不关心您是否超出缓冲区(至少就写入文件而言)。它只是确保缓冲区中的内容进入该文件,并且每个文件都与其他文件隔离。它不需要“保障”,根本没有溢出到下一个文件的机制,用户模式文件系统不是那样构建的
    猜你喜欢
    • 2019-01-31
    • 2020-04-05
    • 2011-04-20
    • 2019-02-20
    • 2019-03-12
    • 2016-02-12
    • 2010-09-20
    • 1970-01-01
    相关资源
    最近更新 更多