I took another look at pyfuse3. It is indeed difficult to port ratarmount to it because it is a fork of llfuse and according to its previous name wraps only the low-level FUSE interface that works with inodes instead of paths. I think this is hard to get to work with ratarmount especially when it comes to such features as merging filesystems or mounting recursively.

I did a small survey on other projects on PyPI:

Project	How it uses FUSE
kaitai_fs	fusepy
gitfs	fusepy 3.01
datalad	depends on `fsspec[fuse]`, which requires fusepy
YubiKey PIV FileSystem	fusepy
ninfs	fusepy. Does not list it in dependencies because of missing Windows support of fusepy. Instead, fuse.py has been copied into this repository.
GitFS	Contains hardcopy of fuse.py with fusepy copyright header
DedupSQLfs	llfuse
borg	Works with both llfuse and pyfuse3?
swh.fuse	pyfuse3
tgmount	pyfuse3
tgcloud	Uses yum python-fuse, so *fuse-python
flumes-fuse	fuse-python 1.0.4
s3monkey	Has the FUSE tag but because Heroku does not allow it, it has a Python interface, so basically like ratarmountcore.
fatx	Manually interfaces with the FUSE C headers without a Python abstraction
aliyundrive-fuse and pikpak-fuse	Rust package that is distributed as a Python module. Looks nice and interfaces directly with the FUSE C API and needs no Python bindings in between! Not entirely sure where the entry point for the Python package is, only main for a command line interface?
fox-it/dissect	fusepy3, fork of fusepy with libfuse3 support. Last update 9 months ago.

These are not handpicked, so it looks to me like everything that exists to interface FUSE is used roughly equally in this quite small sample set and fusepy is used a little bit more. Borg has a quite reasonable approach of supporting both llfuse and pyfuse3 but it still has to use the low-level API, which I'm hesitant to use.

I see two possibilities:

Use pyfuse3 and implement an inode-to-path cache like high-level FUSE does internally. Of course this would mean reimplementing performance-critical facilities, which already exist in C FUSE, in Python. This seems like a waste and has many pitfalls regarding performance. For example, I cannot just keep growing the "cache" I have to prune it at times to not duplicate paths for millions of files that ratarmount should support. But I'm not quite clear about what the lifetime should be. I guess I could look at how the FUSE high-level API implements this but again, this seems redundant.
Directly interface with FUSE. This is what aliyundrive-fuse and fatx do. To avoid moving away from a pure Python implementation, I would have to do this in another backend maybe something like rfuse or rafuse so basically yet another Python FUSE binding. I might even do it in Rust while am at it. The cargo Python tooling for aliyundrive-fuse looks promisingly lean. Rewriting ratarmount wholly in Rust might be an option but I already tried with C++ and performance wasn't much better if not worse. Furthermore, ratarmount already is ~7.5k lines of Python out of which ~5k are code not counting the tests. It feels hard to port all that while keeping bugs and regressions low.

Dependency fusepy #101

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions