FUSE library options for FileTree / TreeCDRT

API
1

See also investigation of FUSE options by @danda here. I’ve continued from there, and present a summary so far:

Linux/MacOS

Linux/MacOS seems between fuser (fuse-rs clone) and polyfuse because fuse-rs has little activity in recent months. The have more recent activity with one or two current contributors.

  • both fuser and polyfuse are FUSE rewrites in Rust (ie not wrappers around libfuse)
  • the author of fuser responded helpfully to my questions (see fuser issue #3 and polyfuse
  • polyfuse uses an async implementaion using tokio
  • fuser supports Linux/MacOS/FreeBSD
  • polyfuse “only supports the Linux platforms with the FUSE ABI version is 7.23 (2005/6) or higher”.
    I don’t know how hard it would be to add MacOS. I imagine we can use the same method as fuser/fuse-rs but not having a Mac I can’t have a go at that.

CONCLUSION: It seems fairly even. I chose polyfuse for the first test as a way of looking at it more closely and because it is an async implementation (using tokio). I think it fits our need very well. But fuser may be as good, and has better platform support right now. We could try both once the FileTree/TreeCDRT are functional and leave a decision until then.

Windows

Windows: if our Linux/MacOS implementaions use the FUSE low-level API as planned, it is probably less work and easier to maintain compatibility (e.g. with hard-links on all plaforms) if we also use the low-level API on Windows. If so this points towards using WinFUSE so I think that should be our initial choice. There are some concerns about it (see github):

  • “alpha” quality
  • “Finally note that this release contains the winfuse kernel driver, which exposes the FUSE protocol in the Windows kernel (via DeviceIoControl). It does not contain the wslfuse kernel driver, which will expose the FUSE protocol in WSL1 (via /dev/fuse)”

CONCLUSION: There are options on Windows using the high-level FUSE API, but I suggest we leave these until we have looked at using WinFUSE. Note: if we look at the high-level FUSE API for Windows, there’s a library to make Dokan easy to use from Rust (dokan-rust)

2 Likes
2

I just took a look at WinFuse again and it seems it is written in C, not Rust. bummer.

In their diagram on github, it seems that it basically just exposes /dev/fuse to WSL processes. So that makes me wonder if perhaps a safe_fs executable built with rust crate such as fuse-rs could in fact work, as I believe it simply read/writes /dev/fuse. Perhaps just wishful thinking, but maybe…?

any windows users here that could try it out, perhaps using something like bpfs?

Otherwise, maybe it wouldn’t be too hard to write some rust bindings…

If any community member interested in tackling this, let me know.

I’ve just been doing a bit of thinking about how best to handle cross-platform issues. Considering there are different use-cases: backup/restore, sharing, deployment, etc. more on that later.

1 Like