// overview

Introduction

PrismaFS is a userspace filesystem, built on FUSE and macFUSE. First step is mounting directory or directories from where you can point PrismaFS to your HOME path, project tree, read-only volumes, or any other path, and then read, write, create, delete, and rename files. Multiple source directories can exist, with your session working directory having top priority. So, “session” is type of 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 files/directories over the mount, PrismaFS first looks for it in your session directory. If its not there, it reads from source. If you write to it, PrismaFS copies it into your session first, then writes there. If you delete any files found only in source, PrismaFS tracks that in session space (hidden marker file), and those file disappear from the mounted view. In all three cases, source is unmodified.

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

This model of layered design is inspired by Plan 9 model of filesystem namespaces. However, Plan 9 applied this at operating system / kernel design level (per-process). On standard UNIX and UNIX-like operating systems, filesystem namespace is global and shared. Getting the isolated working copy of 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 any path points to, but never affecting another process. For example, you could give one process view of / that has different bin, different usr, different etc, while everything else on your system sees the original. Any terminal session is a process. In one terminal you could have different content in the same HOME path, for that session, and other terminals opened outside of namespace session will see originals. This isolation at filesystem level was built into operating system itself.

Plan 9 is not UNIX but intended to take the UNIX philosophy to the next step with distributed computing concept 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 kernel rewrite 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 large class of tasks, in order to get isolated view of directory tree, test a dependency without affecting your real environment, or simply experiment with directories without risk, the overhead is real. There is also inconvenience for the fact that these solutions are not unified, standardized, or POSIX compliant between different UNIX-like operating systems and environments.

PrismaFS aims to bring this filesystem aspect to userspace on macOS, Linux, and FreeBSD, as closely and effectively as possible.

This is the official check for release v1.7.1 (first milestone): Release v1.7.1 test cases.

Reporting issues on GitHub Issues is encouraged. Examples and install are tested, but if in your case a particular problem arises, or you need help, open issue there. I am good to be contacted. When reporting, please paste exact order of commands you ran and the full outputs.