FuseSharp | FUSE wrapper in .NET Standard | File Utils library

FuseSharp is a C# library typically used in Utilities, File Utils applications. FuseSharp has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

Filesystems in macOS live in the kernel, and as such any modifications would require kernel extensions. To avoid this, FUSE (Filesystem in USErspace) was developed. It allows userspace programs to supply a filesystem to the kernel. The developer is thus free to implement the filesystem however they wish. The FUSE project consists of two components: the FUSE kernel module, and the LIBFUSE userspace library. LIBFUSE provides the reference implementation for communicating with the FUSE kernel module. A FUSE filesystem is typically implemented as a standalone application tthat links with LIBFUSE. The later provides functions to mount the filesystem, unmount it, read requests from the kernel, and send responses back. In addition to registering a new filesystem, FUSE's kernel module also registers a /dev/fuse block device. This device serves as an interface between user-space FUSE daemons and the kernel. In general, daemon reads FUSE requests from /dev/fuse, processes them, and then writes replies back to /dev/fuse. The figure shows FUSE's along with FuseSharp high-level architecture. When a user application performs some operation on a mounted FUSE filesystem, the VFS routes the operation to FUSE's kernel driver. The driver then allocates a FUSE request structure and puts it in a FUSE queue. At this point, the process that submitted the operation is usually put in a wait state. FUSE's user-space daemon then picks the request from the kernel queue by reading from /dev/fuse and processes the request. Processing the request might require entering the kernel again: for example, in case of a stackable FUSE filesystem, the daemon submits the operations to the underlying filesystem (e.g., EXT4); or in case of a block-based FUSE filesystem, the daemon reads or writes from the block device. When done with processing the request, the FUSE daemon writes the response back to /dev/fuse; FUSE's kernel driver then marks the request as completed and wakes up the original user process. Some filesystem operations invoked by an application can complete without communicating with the user-space FUSE daemon. For example, reads from a file whose pages are caches in the kernel page cache, do not need to be forwarded to the FUSE driver. FuseSharp also consists of two components. An Adaptor.dylib library that wraps calls to the libfuse library, and the FuseSharp DLL itself, which communicates with the former through a set of callbacks passed down using the pinvoke mechanism. We took this aproach because we found that the libfuse library is complicated and very poorly documented (the code is the documentation, but the complexity of the code makes it difficult to easily understand its intention). This Adaptor library, written in C, implements the key steps of setting up a communication channel with the FUSE kernel, and the processing loop, in a simpler way that handling all at once in .NET space. FuseSharp leverages modern .NET approaches to file handling, threading and memory management, and exposes a modern API designed specifically to enable the development of userspace filesystems, through a simple architecture implemented solely using .NET Standard.