Uses old Rust 2015
|0.3.1||Nov 8, 2017|
|0.3.0||Jan 6, 2017|
|0.2.8||Jul 30, 2016|
|0.2.7||Sep 8, 2015|
|0.2.0||Dec 24, 2014|
#268 in Filesystem
2,057 downloads per month
Used in 26 crates (23 directly)
This library does not just provide bindings, it is actually an improved rewrite of the original FUSE C library to fully take advantage of Rust's architecture.
A working FUSE filesystem consists of three parts:
- The kernel driver that registers as a filesystem and forwards operations into a communication channel to a userspace process that handles them.
- The userspace library (libfuse) that helps the userspace process to establish and run communication with the kernel driver.
- The userspace implementation that actually processes the filesystem operations.
The kernel driver is provided by the FUSE project, the userspace implementation needs to be provided by the developer. This Rust library provides a replacement for the libfuse userspace library between these two. This way, a developer can fully take advantage of the Rust type interface and runtime features when building a FUSE filesystem in Rust.
Except for a single setup (mount) function call and a final teardown (umount) function call to libfuse, everything runs in Rust.
To run a program that mounts a FUSE filesystem, the target system needs FUSE (OSXFUSE on macOS) to be properly installed (i.e. kernel driver and libraries. Some platforms may also require userland utils like
fusermount). A default installation of package
fuse on Linux or installing
OSXFUSE on macOS is usually sufficient.
To build, the host system needs FUSE libraries and headers installed. On Linux, the package is usually called
libfuse-dev. On macOS,
OSXFUSE installs everything that's needed. The build process also requires
pkg-config to locate headers and libraries.
Put this in your
[dependencies] fuse = "0.3"
and in your crate root:
extern crate fuse;
To create a new filesystem, implement the trait
Filesystem. Filesystem operations from the kernel are dispatched to the methods of the
Filesystem trait. Most methods get a
reply parameter that must be used to eventually answer the request. All methods have default implementations that reply with neutral answers, so if you implement no method at all, you still get a mountable filesystem that does nothing.
To actually mount the filesystem, pass an object that implements
Filesystem and the path of an (existing) mountpoint to the
mount will not return until the filesystem is unmounted.
To mount a filesystem and keep running other code, use
spawn_mount instead of
spawn_mount spawns a background thread to handle filesystem operations while the filesystem is mounted. It returns a handle that should be stored to reference the mounted filesystem. If the handle is dropped, the filesystem is unmounted.
To unmount a filesystem, use any arbitrary unmount/eject method of your OS.
See the examples directory for some basic examples.
There's still a lot of stuff to be done. Feel free to contribute.
- Interrupting a filesystem operation isn't handled yet.
- An additional more high level API would be nice. It should provide pathnames instead inode numbers and automatically handle concurrency and interruption (like the FUSE C library's high level API).
In general, see the list of issues on GitHub and search the source files for comments containing "TODO" or "FIXME" to see what's still missing.
Support for FUSE on FreeBSD is currently untested (but probably works with minor adjustments).