- 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: 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)