Filesystem API that takes paths instead of inode numbers about fuse-rs HOT 5 OPEN

I'll add mention that a path name based API had the disadvantage of making it impossible to create a posix compliant (aka correct) file system. Unless you do not, for instance allow file deletion. So it would be ideal to make this clear in the documentation for any such API.

A path name based API is not a safe and easy API, but rather an easy but sloppy and incorrect API.

from fuse-rs.

I want to qualify what I wrote about a path name based API. Such an API can (I think) be entirely safe, if you force the use of the "fh" field when appropriate, e.g. by not providing paths on read/write, etc. So far as I know this would make the API safe, since then when a file is opened, you'd have to create some sort of reference to it other than its path, so it could continue being read after it is deleted.

from fuse-rs.

The idea is not to modify the current API to take paths, but to have an additional API.
Using paths is convenient, but it adds the overhead of lookups or conversion functions since the kernel internally always works with inodes. So, the existing Filesystem trait is supposed to stay like this (libfuse has fuse_lowlevel_ops) for a minimal-overhead interface.
An API with paths would internally again use the API with inodes and "just" needs to convert between paths and inodes. This shouldn't be too hard and could be done with lookup tables (HashMap) or by using path hashes as inode numbers. But unfortunately, nobody has taken the time to design it yet.

from fuse-rs.

I came accross https://github.com/anowell/netfuse just now, which seems to be good enough for most basic operations (it's missing lots of ops though).

from fuse-rs.

I'm also working on https://github.com/wfraser/fuse-mt which sits on top of rust-fuse and does inode->path translation, and adds multi-threading for some I/O operations. It's a work-in-progress that I haven't had much time to work on lately, though.

from fuse-rs.