我可以在 Windows 中创建一个只存在于内存中的文件 - 如果可以，如何创建? [英] Can I create a file in Windows that only exists in memory - and if so, how?

问题描述

_{这个问题不是任何这些现有问题的重复:}

• _{如何将仅存在于内存中的对象文件存储为存储系统内的文件? - 这个问题与 Java 的 File 无关API.}
• _{仅存在于 RAM 中的临时文件?- 这与我要问的很接近，除了 OP 没有询问如何从内存中创建文件以共享将它们传递给子进程}
• _{我也不是询问 Win32 的内存映射文件 - 因为它们本质上与我所追求的相反:内存映射文件是一个文件映射到进程的虚拟内存空间的磁盘 - 而我想要的是存在于操作系统文件系统(但不是磁盘的物理文件系统)中的文件，如挂载点，并且该文件的数据映射到内存中的现有缓冲区.}
  • _{即，对于内存映射文件，在特定缓冲区地址和内存中的偏移量写入/写入字节将导致与文件开头相同偏移量的字节被修改 - 但文件物理上存在于磁盘上，这不是我想要的.}
  • _{How can I store an object File that only exists in memory as a file inside of my storage system? - This question is not about Java's File API.}
  • _{Temp file that exists only in RAM? - This is close to what I'm asking, except the OP isn't asking how to create files from memory for the purposes of sharing passing them to child-processes}
  • _{I'm not asking about Win32's Memory-mapped File either - as they're essentially the opposite of what I'm after: a memory-mapped file is a file-on disk that's mapped to a process' virtual memory space - whereas what I want is a file that exists in the OS' filesystem (but not the disk's physical filesystem) like a mount-point and that file's data is mapped to an existing buffer in memory.}
    • _{I.e., with Memory Mapped Files, writing/writing to a byte at a particular buffer address and offset in memory will cause the byte at the same offset from the start of the file to be modified - but the file physically exists on-disk, which isn't what I want.}

    详细说明并提供上下文:

    To elaborate and to provide context:

    • 我有一个 ASP.NET Core 服务器端应用程序，它定期接收大小在 1 到 10MB 之间的请求流.此程序将仅在 Windows/Windows Server 上运行，因此使用 Windows 特定的功能没问题.
    • 75% 的时间我的应用程序只是自己读取这些流，仅此而已.

    • 但在少数情况下，它需要让单独的应用程序读取数据，然后使用 Process.Start 开始并将文件名作为命令行参数传递.

    • I have an ASP.NET Core server-side application that receives request streams sized between 1 and 10MB on a regular basis. This program will run only on Windows / Windows Server, so using Windows-specific functionality is fine.
    • 75% of the time my application just reads through these streams by itself and that's it.

    • But a minority of the time it needs to have a separate applications read the data which it starts using Process.Start and passing the file-name as a command-line argument.

    • 它通过将流保存到磁盘上的临时文件并传递该流的文件名来将数据传递给这些单独的应用程序.
    • 不幸的是，它无法将内容写入子进程的 stdin，因为其中一些程序需要磁盘上的文件，而不是从 stdin 读取.
    • It passes the data to these separate applications by saving the stream to a temporary file on-disk and passing the filename of that stream.
    • Unfortunately it can't write the content to the child-process's stdin because some of the those programs expect a file on-disk rather than reading from stdin.

    此外，虽然运行它的机器有大量 RAM(因此将流缓存在内存中很好)，但它有缓慢的旋转锈 HDD，这是进一步的原因避免磁盘上的临时文件.

    Additionally, while the machine it's running on has lots of RAM (so keeping the streams buffered in-memory is fine) it has slow spinning-rust HDDs, which is further reason to avoid temporary files on-disk.

    我想避免不必要的缓冲和复制 - 理想情况下，我想将整个 1-10MB 请求流式传输到单个内存缓冲区中，然后将相同的缓冲区暴露给其他进程 并使用相同的缓冲区作为临时文件的后备.

    I'd like to avoid unnecessary buffering and copies - ideally I'd like to stream the entire 1-10MB request into a single in-memory buffer, and then expose that same buffer to other processes and use that same buffer as the backing for a temporary file.

    如果我在 Linux 上，我可以使用 tmpfs - 它并不完美:

    If I were on Linux, I could use tmpfs - it isn't perfect:

    • 据我所知，现有进程无法指示操作系统获取其虚拟内存的现有区域并将 tmpfs 中的文件映射到该内存区域，而是 tmpfs 仍然需要通过将所有数据写入(即复制)到其文件描述符来填充文件 - 这与拥有零复制系统的目标背道而驰.
    • To my knowledge, an existing process can't instruct the OS to take an existing region of its virtual-memory and map a file in tmpfs to that memory region, instead tmpfs still requires that the file be populated by writing (i.e. copying) all of the data to its file-descriptor - which is counter to the aim of having a zero-copy system.

    Windows 的内置 RAM 磁盘功能仅限于通过第三方设备驱动程序为 RAM 磁盘实现提供基础 - 我很惊讶 Microsoft 从未随 Windows 提供内置RAM 磁盘 GUI 或 API，特别是考虑到它们相对简单.

    Windows' built-in RAM-disk functionality is limited to providing the basis for a RAM-disk implementation via a third-party device-driver - I'm surprised that Microsoft never shipped Windows with a built-in RAM-disk GUI or API, especially given their relative simplicity.

    • ImDisk 程序是一个使用 Microsoft 的 RAM 磁盘驱动程序平台实现 RAM 磁盘，但据我所知，虽然它更像是 tmpfs，因为它可以创建仅存在于内存中的文件，但它不会t 允许文件的数据由运行进程直接访问的缓冲区(或共享内存缓冲区)提供支持.
    • The ImDisk program is an implementation of a RAM-disk using Microsoft's RAM-disk driver platform, but as far as I can tell while it's more like tmpfs in that it can create a file that exists only in-memory, it doesn't allow the file's data to be backed by a buffer directly accessible to a running process (or a shared-memory buffer).

    推荐答案

    CreateFileMapping with hFile = INVALID_HANDLE_VALUE "创建由系统支持的指定大小的文件映射对象分页文件而不是文件系统中的文件".

    CreateFileMapping with hFile = INVALID_HANDLE_VALUE "creates a file mapping object of a specified size that is backed by the system paging file instead of by a file in the file system".

    来自 Raymond Chen 的 很多困惑的根源:由系统支持分页文件":

    From Raymond Chen's The source of much confusion: "backed by the system paging file":

    换句话说，由系统页面文件支持"只是意味着像普通虚拟内存一样处理".

    In other words, "backed by the system paging file" just means "handled like regular virtual memory."

    如果内存在被分页之前被释放，那么它永远不会被写入系统分页文件.

    If the memory is freed before it ever gets paged out, then it will never get written to the system paging file.

    这篇关于我可以在 Windows 中创建一个只存在于内存中的文件 - 如果可以，如何创建?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！