# Survey of RUST/FUSE FileSystem Libraries.

###### tags: `filesystem` `fuse`

We are looking for a library or set of libraries that would enable us to have a single SAFE Network FileSystem codebase that operates on both unix and windows platforms.

With that in mind, we list some options below:

|Library/Crate|Platform(s)|Rust?|Stable?|Notes|
|-------------|--|----|-----|-------|
|[WinFuse](https://github.com/billziss-gh/winfuse)|Windows|Rust|No|supports WSL. Recommended [here](https://github.com/zargony/fuse-rs/issues/76#issuecomment-624880608).|
|[fuse-rs](https://github.com/zargony/fuse-rs)|Linux,MacOS,FreeBSD|Rust|?|fully rust, not C bindings|
|[Dokany](https://github.com/dokan-dev/dokany)|Windows|C++|?|use native windows API, but also includes [dokan_fuse API](https://github.com/dokan-dev/dokany/wiki/FUSE), in C++. Edward used this for [Safe.NetworkDrive](https://github.com/oetyng/SAFE.NetworkDrive)|
|[dokan-rust](https://github.com/dokan-dev/dokan-rust)|Windows|Rust|?|[Unclear](https://github.com/zargony/fuse-rs/issues/76#issuecomment-267600155) if dokan-rust provides access to dokan_fuse API. more investigation needed.|
|[fuse-mt](https://github.com/wfraser/fuse-mt)|Linux,MacOS,FreeBSD|Rust|?|fuse-rs fork. multi-threaded, path based API instead of Inode number.|
|[polyfuse](https://crates.io/crates/polyfuse)|Linux,MacOS,FreeBSD|Rust|?|fuse-rs fork. Implements async/await|
|[WinFSP](https://github.com/billziss-gh/winfsp)|Windows|C|Yes|includes FUSE compatibility layer. Said to be *very* stable. No rust bindings|

WSL = Windows Subsystem for Linux.

### Initial Impressions

On the unix side, fuse-rs is the most used and should be the most stable. At the same time, fuse-mt and polyfuse may be worth trying out since they have some desirable features. The fact that fuse-mt is path based (rather than inode) should make it easier to use, but also may create problems trying to share a single codebase with Windows.

On the windows side, WinFuse may be the only real option for fuse+rust. There is dokan-rust, but it doesn't appear that it offers fuse compatibility. Probably it could still be used as the [API mapping](https://github.com/dokan-dev/dokany/wiki/FUSE#fuse--dokan-map) is close, we would just need a translation layer between the platform-independent lib and dokan-rust.

### Fuse Low Level API vs High Level API

The C FUSE library offers [2 API levels](http://libfuse.github.io/doxygen/):

The Low level API operates on inodes and is async. The high level API operates on paths and is sync.

> libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be sent explicitly using a separate set of API functions.

Performance of the 2 APIs is reportedly similar. Which to use depends more upon use-case. [Discussion](http://fuse.996288.n3.nabble.com/Fuse-low-level-APIs-vs-high-level-td11940.html) Except:

> When using the high level API, hard-linked files are replicated in the cache, which lead to inconsistencies unless you force zero for the cache duration. You do not have this issue with the low level API.

What about rust libraries?
* fuse-rs uses inodes.
* polyfuse uses inodes.
* fuse-mt uses paths.
* syncer uses fuse-mt, (paths)

on Windows:
* WinFuse uses inodes.
* dokan-fuse uses paths, but not implemented by dokan-rust.
* winfsp fuse compat layer uses paths, but no rust impl.

Path based API sounds attractive because we really don't have an Inode concept in SAFE. (Maybe an inode u64 can be mapped to an xorname?) However, for code portability between linux and windows, it may be better to use the low-level API, if possible.

To go with path based API, the SAFE team may need to provide rust port or wrappers for either winfsp or dokan-fuse.

Background on inode vs path API support in windows can be found [here](https://github.com/zargony/fuse-rs/issues/76) and [here](https://github.com/billziss-gh/winfsp/issues/94).

## Fuse Network Filesystems

We aren't the first to create a networked files system. We might take some inspiration from other projects.

### Rust/Fuse

|Library/Crate|FuseAPI|Notes|
|-------------|----|---|
|[Syncer](https://github.com/pedrocr/syncer)|rust-mt (path)|A filesystem that pretends you have all your files locally while caching only the most recently used. syncs via rsync over ssh|
|[OneDrive Fuse](https://crates.io/crates/onedrive-fuse)|fuse-rs (inode)|access MS OneDrive cloudstorage. Only partially complete.|
|[NetFuse](https://crates.io/crates/netfuse)|fuse-rs (inode)|tagline: *The fastest way to POC a network-backed filesystem.* provides an internally managed inode cache that allows abstracting FS operations into operations on paths. It is designed with the assumption that the backing store is over a network, so the implementation relies heavily on caching and lazy writing to improve perceived performance. last update: 2018.|
|[soundcloud-fs](https://crates.io/crates/soundcloud-fs)|fuse-rs (inode)|a FUSE driver to serve audio files from SoundCloud. It is optimized to avoid needless API requests and aid mass indexing by music libraries, specifically MPD. last update Apr 2020|
|[GCSF](https://crates.io/crates/gcsf)|fuse-rs (inode)|GCSF is a virtual filesystem that allows users to mount their Google Drive account locally and interact with it as a regular disk partition. more in this [paper](https://sergiu.ml/~sergiu/thesis.pdf).|

### Fuse, Other Languages

|Library/Crate|Language|FuseApi|Desc|Notes|
|-------------|---|--|--|--|
|[ipfs](https://github.com/ipfs/go-ipfs/tree/master/fuse)|Go|?|Interplanetary FS. |Faces similar issues as Safe Network. two mount points: /ipfs and /ipns. after you use “ipfs daemon --mount”… you mount /ipfs/ as a read only directory but /ipns/your_id as a read-write directory. [fuse howto](https://willschenk.com/articles/2020/ipfs_and_fuse/). They seem to be using [API abstraction layer](https://github.com/ipfs/go-ipfs/issues/5003#issuecomment-486006313), similar to what we have been thinking of for SAFE Network |
|[s3backer](https://github.com/archiecobbs/s3backer)|C|low (inode)|amazon S3. Uses a single local file to emulate a block device, that any other filesystem can format/mount eg ext2, etc.|intriguing, outside-the-box approach)|
|[s3fs](https://github.com/s3fs-fuse/s3fs-fuse)|C++|high (path)|amazon S3. in-memory metadata caching, local disk data caching||
|[sshfs](https://github.com/libfuse/sshfs)|C|high (path)|mount remote server directory over ssh|has a directory cache.|

## Rust/Fuse In memory FileSystems

|Library/Crate|FuseApi|Notes|
|-------------|--|--|
|[bpfs](https://github.com/bparli/bpfs)|fuse-rs (inode)|bpfs is a an in-memory filesystem written in Rust and built on the Rust-FUSE library|