mfusepy is a Python module that provides a simple interface to FUSE and macFUSE. It's just one file and is implemented using ctypes to use libfuse.

Via PyPI:

pip install mfusepy

You also need to install the fuse (2) or fuse3 package on your system.

This version tries to follow Semantic Versioning. If you depend on this project, you should fix the major version, or else you risk your project breaking on a newer version release! E.g., in your pyproject.toml:

dependencies = ["mfusepy ~= 1.1",]

If you have tested with multiple major versions and they are known to work, you can relax the constraint for maximum compatibility:

dependencies = ["mfusepy >= 1.1, < 3.0",]

This is a fork of fusepy because it did not see any development for over 6 years. Refuse was an attempt to fork fusepy, but it has not seen any development for over 4 years. Among many metadata changes, it contains two bugfixes to the high-level API, which I have redone in this fork. See also the discussion in this issue. I intend to maintain this fork as long as I maintain ratarmount, which is now over 5 years old.

The main motivations for the fork are:

• FUSE 3 support. Based on the libfuse changelog, the amount of breaking changes should be fairly small. It should be possible to simply update these ten or so changed structs and functions in the existing fusepy.
• Translation layer performance. In benchmarks for a simple find call that lists all files, some callbacks such as readdir turned out to be significantly limited by converting Python dictionaries to ctype structs. The idea would be to expose the ctype structs to the fusepy caller.
  • Much of the performance was lost trying to populate the stat struct even though only the mode and inode member are used by the kernel FUSE API.

The prefix m in the name stands for anything you want it to: "multi" because multiple libfuse versions are supported, "modded", "modern", or "Maximilian".

All these libraries only wrap the low-level libfuse interface, which works with inodes instead of paths, and therefore are not (easily) usable for my use case. In the end, there is mostly only some path-to-hash table in the high-level libfuse API, but it is cumbersome to implement and performance-critical.

See some examples of how you can use mfusepy:

mfusepy requires FUSE 2.6 (or later) and runs on:

• Linux (i386, x86_64, PPC, arm64, MIPS)
• macOS (Apple Silicon, Intel)
• FreeBSD (i386, amd64)
• NetBSD (amd64)
• OpenBSD (amd64)

While FUSE is (at least in the Unix world) a Linux kernel feature, several user space libraries exist for easy access. libfuse acts as the reference implementation.

• libfuse (Linux, FreeBSD) (fuse.h 2 3)
• libfuse (OpenBSD) (fuse.h 2)
• librefuse (NetBSD) through PUFFS (fuse.h 2)
• macFUSE (macOS), previously called osxfuse, (fuse.h 2 3)
• MacFUSE (macOS), no longer maintained
• FUSE-T (macOS), GitHub
• WinFsp (Windows) (fuse.h 2 3)
• Dokany (Windows) (fuse.h 2)
• Dokan (Windows), no longer maintained

• Megatron-Energon
• ninfs
• ratarmount