Filesystems for people, not operating systems

Draft, here be dragons.
Or, picking a fight with hierarchical filesystems (which is all of them).

Recently I asked myself whether I knew any filesystems specifically meant for users. I define a filesystem meant for users as one that would be meant to contain your home directory and aid you in managing your files. This is in opposition to a filesystem meant for operating systems, meaning one meant to contain your root directory with all of your system files and yes, as an afterthought often your home directory as well.

I realized that I didn’t know any such filesystems meant for users, which I call Human File Systems. During a discussion, my father came up with the Files app on iOS as a possible exception. But the Files app was only reluctantly added by Apple, after people complained for over a decade that they couldn’t use files on iOS. It was not exactly meant to be a revolution, more as a compromise to stop one.

ZFS

I consider ZFS to be a large step forwards for users. It’s less focused on performance and operating systems and more on system administrators. In my view it does however still not cater to actual users.

I personally consider its most important feature to be sharing space between “partitions”
ZFS calls them datasets
. A user with two ext4 partitions on a disk must decide up front how much space each one gets. Changing this allocation is possible but painful and involves manual action and scary commands. ZFS handles this completely automatically, allocating space to whichever data set needs it in a pool without any user interaction.
Optionally limits can be set on a dataset to prevent it from taking up all of the available capacity.

Additional nice features for users include:
  • Snapshots
  • Simplifying backups (zfs send | zfs receive)
  • Redundancy with RAID
  • Compression, this works well for large amounts of plaintext

Semantic and tagging filesystems: Why hierarchical filesystems are actually a good idea.

Hierarchical filesystems give files a specific place in the space of the filesystem. Humans are very good at navigating physical spaces, they also turn out to be pretty good at navigating hierarchical filesystems.

Semantic and tagging filesystems lose this connection to a place. They ask the user to search for stuff using queries
I consider a combination of tags to be a query.
. Although tagging and search systems have shown great promise in collaborative systems of large groups of people (search engines, social media)
See folksonomies
they have consistently sucked for individual usecases.

People consistently seem to prefer navigation over search.

Graph filesystems

I consider the most promising direction to be graph filesystems. It’s a straight-up generalisation of hierarchical filesystems and thus remains backwards-compatible with existing cultural practices around files.

Graph filesystems allow forming heterarchies which can be used to create multiple views into the same information.

I also suspect graph filesystems might be very suitable for AR/VR user interfaces.

URLs and file paths

URLs mimic file paths very closely. There’s even a way to encode file paths in URLs via the file URI.

Nevertheless there is a key difference between URLs and file paths: A file path always encodes a directory or a file, a URL can (although uncommon) be both. A trailing / in a URL is semantically meaningful and can alter the response you get. For URLs, paths can both contain subpaths and data.

This can come in handy. The Rust programming language, for example, uses a mod.rs file to store the data of the module named after its parent directory. In the URL system this is unnecessary.

See https://fkohlgrueber.github.io/blog/tree-structure-of-file-systems/ for more detail.

What now?

Filesystems have been made for operating systems, not users. Changing this will be hard and take a long time, if it succeeds at all. But after over 50 years of hierarchical filesystems I think we should try. Maybe bring back versioning file systems?

There are a plethora of (academic) semantic and tagging filesystems, none of which seem to be actually used in real life. I’ve been experimenting with my own graph filesystem for a while but it’s got a bunch of hardcoding and is very specialized for my precise usecase.
You might call this Situated Software or Home-Cooked Software
It’s still only minimally viable even for my usage, I don’t really see a path to changing that anytime soon.

One thing I wish to highlight is that I think having alternatives to hierarchical filesystems in actual real-world use is crucial. That’s where we’ll find the deficiencies and unexpected benefits or synergies. I believe there are a lot of unknown unknowns about these alternatives.

I am mildly excited and incredibly curious about the future.

Further reading