collapse Table of Contents
  1. Mono.Fuse
    1. Why?
    2. What about SULF?
    3. Additional Information


Mono.Fuse is a binding for the FUSE library, permitting user-space file systems to be written in C#.


I read Robert Love's announcement of beaglefs, a FUSE program that exposes Beagle searches as a filesystem. My first thought: Why wasn't that done in C# (considering that the rest of Beagle is C#)?

What about SULF?

Stackable User-Level Filesystem, or SULF, is a pre-existing FUSE binding in C#, started by Valient Gough in 2004. It has since been replaced by fusewrapper.

Mono.Fuse has no relation to SULF or fusewrapper, for three reasons:

  1. They go to great efforts to avoid a Mono.Posix.dll dependency, duplicating Mono.Unix.Native.Stat (Fuse.Stat), Mono.Unix.Native.Statvfs (Fuse.StatFS), and many methods from Mono.Unix.Native.Syscall (Fuse.Wrapper).
  2. I don't like the SULF API. (Not that I spent a great deal of time looking at it, but what I did see I didn't like.) SULF is an inode-based API, while Mono.Fuse is a path-based API. I think paths are easier to deal with, while Valient Gough believes inodes are.
  3. SULF wraps the FUSE kernel-level interface, while Mono.Fuse wraps the higher level libfuse C interface.

I find (1) the most appalling, if only because I'm the Mono.Posix maintainer and I'd like to see my work actually used. :-)

Once I started writing Mono.Fuse, I discovered a good reason to avoid Mono.Posix: it's currently impossible to use the native MonoPosixHelper shared library from outside of Mono. I figured this would be a good opportunity to rectify that, making it easier for additional libraries to build upon the Mono.Posix infrastructure.

Additional Information

Mono.Fuse was announced on August 29, 2006 on mono-devel-list and my blog.

Mono.Fuse has since been updated so that it doesn't require Mono class library changes, and thus can work on the "stable" Mono 1.1.13.

Source code is available.

A GIT repository is also available at