读取输入文件的内存映射文件有多安全？

Question

将输入文件映射到内存中，然后直接从映射的内存页中解析数据，是一种从文件中读取数据的便捷高效的方式。

但是，除非您可以确保没有其他进程写入映射文件，否则这种做法似乎从根本上也不安全，因为如果底层文件被另一个进程写入，即使私有只读映射中的数据也可能发生变化。 （POSIX 例如doesn't specify“在建立 MAP_PRIVATE 映射后对底层对象所做的修改是否通过 MAP_PRIVATE 映射可见”。）

如果您想在映射文件存在外部更改的情况下确保代码安全，则必须仅通过易失性指针访问映射内存，然后非常小心读取和验证输入的方式，这对于许多用例来说似乎不切实际。

这个分析正确吗？内存映射 API 的文档通常只是顺便提及这个问题，如果有的话，所以我想知道我是否遗漏了什么。

Answer 1

这不是一个真正的问题。

是的，当您映射文件时，另一个进程可能会修改该文件，是的，您可能会看到这些修改。甚至有可能，因为几乎所有操作系统都有统一的虚拟内存系统，所以除非有人请求无缓冲写入，否则不经过缓冲区缓存就无法写入，如果没有人持有映射就无法写入看到变化。
这甚至不是一件坏事。实际上，如果您看不到更改会更令人不安。由于文件在映射时准成为地址空间的一部分，因此您可以看到文件的更改是完全合理的。

如果您使用传统的 I/O（例如 read），在您阅读文件时仍然有人可以修改它。换句话说，将文件内容复制到内存缓冲区并不在存在修改时总是安全的。它是“安全的”，因为 read 不会崩溃，但它确实不保证您的数据是一致的。
除非您使用readv，否则您无法保证任何原子性（即使使用readv，您也无法保证内存中的内容与磁盘上的内容一致，或者在两次调用@ 之间不会改变987654325@)。有人可能会在两次 read 操作之间修改文件，甚至在您进行操作时修改文件。
这不只是没有正式保证但“可能仍然有效”的东西 - 相反，例如在 Linux 下写入明显不是原子的。甚至不是偶然的。

好消息：
通常，进程不只是打开一个任意随机文件并开始写入。当这样的事情发生时，它通常要么是属于进程的众所周知的文件（例如日志文件），要么是您明确告诉进程写入的文件（例如保存在文本编辑器中），或者是进程创建一个新文件（例如，编译器创建一个目标文件），或者该过程只是追加到现有文件（例如，db journals，当然还有日志文件）。或者，一个进程可能会自动将一个文件替换为另一个文件（或取消链接）。

在任何情况下，整个可怕的问题都归结为“没有问题”，因为要么您很清楚将会发生什么（因此这是您的责任），要么它可以无缝运行而不会受到干扰。

如果您真的不喜欢另一个进程可能在您映射文件时写入文件的可能性，您可以在 Windows 下创建文件句柄时简单地省略 FILE_SHARE_WRITE。 POSIX 使它有点复杂，因为您需要fcntl 强制锁的描述符，这不是每个系统都必须支持或 100% 可靠的（例如，在 Linux 下）。

Answer 2

理论上，如果有人这样做，您可能会遇到真正的麻烦 在阅读时修改文件。在实践中：你是 读取字符，仅此而已：没有指针或任何东西 这可能会给你带来麻烦。在实践中......正式地， 我认为它仍然是未定义的行为，但它是一种 我认为你不必担心。除非修改 非常小，你会得到很多编译器错误，但那是 快结束了。

可能导致问题的一种情况是，如果文件是 缩短。我不确定当你阅读时会发生什么 结束之后。

最后：系统不会随意打开和 修改文件。这是一个源文件；这将是一些白痴 做这件事的程序员，他应得的。在没有 情况下您未定义的行为是否会破坏系统或其他 人民档案。

还要注意，大多数编辑都在私人副本上工作；当。。。的时候 回写，他们通过重命名原件来做到这一点，并创建 一个新文件。在 Unix 下，一旦你打开文件到mmap 它，所有重要的是inode编号。而当编辑 重命名或删除文件，您仍然保留您的副本。这 修改后的文件将获得一个新的 inode。你唯一需要做的 担心的是如果有人打开文件进行更新，然后 到处修改它。没有多少程序在文本上这样做 文件，除了在末尾附加额外的数据。

所以虽然正式，但有一些风险，我认为你不必这样做 担心它。 （如果你真的很偏执，你可以关掉 在mmaped 时写授权。如果有 真的是敌方特工来抓你的，他可以马上把它转回来 开。）