// overview

Introduction

PrismaFS is a userspace filesystem, built on FUSE and macFUSE. It mounts a directory from which you can point PrismaFS at your home directory, project tree, read-only volumes, or any other path, and then read, write, create, delete, and rename files. Multiple source directories can be stacked by priority, with your session working directory having top priority. So, “session” is a mounted view of one or more sources, with dedicated writable/working space for all changes made in that session. One of the main points is that the original source directory is never touched.

When you work with a file through the mount, PrismaFS first looks for it in your session directory. If it's not there, it reads from the source. If you write to it, PrismaFS copies it into your session first, then writes there. If you delete a file found only in source, PrismaFS tracks that in session space (hidden marker file), and the file disappears from the mounted view. In all three cases, source is unmodified.

What this gives you is a full, working view of any source directory with full read/write access, and every actual change stays isolated. When you are done, unmount and delete the working directory. Nothing you did affected the source.

You can point PrismaFS at your home directory, project tree, read-only volumes, or any other path. Multiple source directories can be stacked by priority, with the scratch space sitting on top. So, “session” is a mounted view of one or more sources, with dedicated writable/working space for all changes made in that session.

This model of layered design is inspired by the Plan 9 model of filesystem namespaces. However, Plan 9 applied this at operating system design level (per-process). On standard UNIX and UNIX-like operating systems, the filesystem namespace is global and shared. Getting an isolated working copy of a directory, be it a home folder, config tree, read-only volume, or any other path, normally means you need a container, VM, or bind-mount with required root access.

In Plan 9, every process has a private namespace, which is its own view of the filesystem. A process can bind any directory into any other path, combine multiple directories together at the same mount point, and/or replace what a path points to, but never affecting any other process. For example, you could give one process a view of / that had a different bin, different usr, different etc, while everything else on the system sees the original. This isolation at filesystem level was built into the very operating system.

Plan 9 is not UNIX but intended to take the UNIX philosophy to the next step with distributed computing and namespace ideas. It is still developed today as 9front.

UNIX came before these ideas and implies decades of software, tooling, and institutional use that would make rewriting a kernel in this way impossible. So instead, filesystem isolation on UNIX took the form of different solutions, such as chroot, BSD jails, Solaris zones, Linux namespaces and cgroups, eventually Docker and other container runtimes, as well as VMs for hardware separation and isolation. Some of these are good solutions, but are often heavyweight, complicated, require elevated privileges, and do not feel like small composable CLI tools. For a large class of tasks, in order to get an isolated view of a directory tree, test a dependency without affecting your real environment, or simply experiment with a directory without risk, the overhead is real. There is also a problem of these solutions not being unified, standardized, or POSIX compliant between different UNIX-like operating systems and environments.

PrismaFS aims to bring the filesystem part of that to userspace on macOS, Linux, and FreeBSD.