search

zargony / fuse-rs

Rust library for filesystems in userspace (FUSE)
MIT License
1.07k stars 129 forks source link

Filesystem API that takes paths instead of inode numbers #75

Open mohsen3 opened 8 years ago

mohsen3 commented 8 years ago

In the todo section of the README file, it is mentioned:

An additional more high level API would be nice. It should provide pathnames instead inode numbers ...

This is what I need. I wonder if there has been any progress on this so far? I changed some of the functions such as getattr and readdir in the Filesystem trait to take Path as a parameter. But later, I noticed that the path only contains the current directory name (rather than the full path). lookup already receives the path, but it has the same problem.

Is there any way to receive the full path in Filesystem? I can definitly make a higher level abstraction that keeps track of inodes <-> paths in a dictionary and passes the full path to the functions instead. Is there any easier/more efficient way to get the full path?

zargony commented 8 years ago

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.

roblabla commented 8 years ago

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

wfraser commented 8 years ago

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.

droundy commented 6 years ago

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.

droundy commented 6 years ago

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.