Simplifying your FUSE routine with MFM
Seeking a simpler way to handle FUSE filesystems, I designed a solution that combines the customizable aspects of userspace file management with the convenience of straightforward, no-frills functionality.
1 hour a day
Every day, I carve out what I optimistically call “1 hour” for coding, a ritual that helps me blend my interest in open-source software with the demands of my day-to-day work. Finding this rhythm took time, especially with the unpredictable nature of entrepreneurship, but this special moment, at least four times a week, provides consistency (and a much-needed escape from the surrounding madness).
Whether in the calm of the morning or the tranquility of the night, this hour is more than just a task to check off my list; it’s actually quite therapeutic, in the end. It’s a commitment I make towards open-source software - a strong belief that gradually materializes through the projects I contribute to.
During this time, I immerse myself in various aspects of open-source contribution. Whether it’s improving user experience by fixing bugs, creating missing features, or translating interface texts to make them clearer, each change is a small success and reinforces my slightly idealistic vision of technology as accessible and shared.
Adressing a purely technical need
In the context of my daily use of FUSE file systems, where sshfs, httpdirfs, gocryptfs are regular tools for accessing remote server folders or securing confidential data, a few years ago, I coded Qasim, a simple graphical application: It resided in my desktop’s system-tray, offering a simplified menu for mounting and unmounting SSHFS systems. It worked for a while, until the Ruby wrapper for Qt5 became incompatible with recent versions of Qt. This was a serious setback for the utility and longevity of Qasim.
I ended up using Sirikali, because everyone seems to recommend it, because it supports multiple fuse filesystems, and it’s graphical. But frankly, it’s less convenient to use than the late Qasim, and the interface is unreadable for me.
Faced with these constraints, I considered an alternative solution that moved away from the graphical interface and closer to the console, more in line with the practices of advanced users: it is with this mindset that MFM was conceived (MFM stands for Minimalist Fuse Manager, because anything minimalist is inherently trendy and cool).
An ode to simplicity
MFM boils down to a utility that offers a menu to mount and unmount file systems on demand. This tool aims to simplify interaction with various types of file systems for IT professionals.
Its operation is straightforward: users must first configure these systems via a YAML file (only once), then launch MFM, choose the file system, and, if necessary, enter a password. The system is then mounted or unmounted without further complication.
Example YAML configuration:
---
version: 1
global:
mountpoint: "/mnt"
filesystems:
- type: gocryptfs
name: "Personal - Encrypted Credentials"
encrypted_path: "/path/to/credentials/vault"
- type: httpdirfs
name: "Public - Remote Debian Repository"
url: "http://ftp.debian.org/debian/"
- type: sshfs
name: "Personal - Remote Media Server"
remote_user: ""
remote_host: mediaserver.local
remote_port: 22
remote_path: "/remote/path/to/media"
#
Developed in Crystal, a language appreciated for its clear syntax and features of static typing and compilation, MFM combines efficient development and error minimization. Its command-line interface relies on fzf for navigation and filtering. In the background, MFM uses specific FUSE file system commands, such as sshfs, httpfs, gocryptfs, and others.
My humble hopes for MFM
MFM, currently in its alpha phase, already provides me with enough stability to have replaced Sirikali in my daily activities. My short-term goal is to refine the error management still present and to improve the FUSE file system configuration process, which currently requires the user to write a YAML file.
Drawing on lessons from Qasim and Qt, I chose to limit MFM’s dependencies to the essential file system mounting commands and fusermount -u. Currently, I am developing an alternative branch where fzf could be replaced by an interface built around the crystallabs/tput.cr library.
Regarding configuration, it is already templated through Jinja, allowing the injection of environmental variables in double braces ``. Using Crinja, I could i theory use conditional blocks and filters. I am exploring using this flexibility to enhance MFM features, like integrating variables directly related to the characteristics of the file systems, although I am still defining the functional limits of this feature.
The future of MFM is written with the community. I invite all tech enthusiasts to contribute, test, and shape a tool that strengthens user autonomy in file management.
If you’re curious about the diversity of actions possible with file systems (and their composition!), MFM might just enrich your experience. I need your feedback to understand what works, what needs improvement, and to confirm the interest in new ideas.
I encourage you to visit the code repository or get the latest binaries, test it in your respective environments, and share your impressions with me. Your feedback is an essential echo for the evolution of MFM.