File system abstraction

[td_]

Has there been any thought about creating an abstraction that could represent file system access (as a trait or maybe something else)? That is, an abstraction that isn’t bound to the actual local filesystem. This isn’t a pre-RFC because I’m not really sure what it would look like. Probably a trait implemented by File or a type parameter (defauling to File) on OpenOptions (or both)?

The goal for me would be to be able to write code that can be tested without touching the disk. Though reading and writing can be abstracted, if code needs to access actual file locations, I don’t know a way to test it without setting up a mock directory. I’d much rather be able to mock the file system in memory.

Possibly there are other uses when you have multiple filesystems coexisting but I’m not sure.

[sfackler]

For reference, Java added this kind of abstraction in 1.7: http://docs.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html. JimFs is an example of an in memory FS designed for testing: https://github.com/google/jimfs.

[td_]

It’s occurred to me that another possible path could just to piggy-back on whatever cross-compilation solutions are implemented, since that’s already a near-term priority. An alternative libstd/sys could be implemented with an in-memory file system (and other kinds of mock io), and people could link their code with that version of std during testing. This would be cleaner than requiring explicit abstraction.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.