In-Memory Filesystems in Rust

Summary

18 Aug 2025In-memory Filesystems in RustI’ve been working on a CLI tool recently, and one of the things it does is manage files on disk. I have written a lot of file management tests for Bundler, and the two biggest reasons that the Bundler test suite is slow are exec and fstat. Knowing that, I thought I would try to get out ahead of the slow file stat problem by using an in-memory filesystem for testing.A collaborator mentioned being happy with the Go package named Afero for this purpose, and so I set off to look for a Rust equivalent to Afero. Conceptually, I was hoping to be able to replace std::fs:: with mycli::fs:: and swap out the backend in tests for something that’s completely in-memory so I don’t have to spend time waiting for syscalls.Unfortunately, based on my searching, not only is there nothing like Afero, but simply asking about it gets you a lecture about how such things aren’t necessary in Rust. Somewhat frustrated, I continued searching and eventually found a few options to try.First, I discovered the vfs crate, whose documentation seems pretty promising. It’s possible to swap out vfs backends to get a real filesystem, an in-memory filesystem, a new filesystem scoped into a directory, or files embedded in an executable. It’s actively maintained, and seems to have a decent number of current users. Unfortunately, as I got further along, it became apparent that the vfs crate isn’t actually a viable alternative to interacting directly with the filesystem.The vfs crate doesn’t have any support for symlinks, so resolving symlinks means going back to std::fs after all, and having to write special-cased symlink resolution code that doesn’t run if the filesystem is vfs. The real killer, though, was that vfs doesn’t contain any support for the concept of file permissions. Because of that, it’s impossible to write executables, which is core functionality for my tool.It turns out the intended primary use case of the crate is to store files inside Rust binaries ...