Bill Fraser

File handles are used when working on an opened file. When FUSE calls `open`, you can give it some arbitrary u64 as a handle, and then when FUSE calls `read`,...

The file handles are optional for some calls because kernel may call them with or without having previously opened the file. Using `chmod` as an example again: there exist two...

> For read-only filesystems to be easier to write? Pretty much, yeah. FUSE gives us the file handle and the inode number, and Fuse-MT maintains an inode path mapping, so...

This is an interesting idea, and I think it's worth looking into. I'm currently just beginning to learn the Futures / Tokio framework. I took a very brief stab at...

Actually, I got motivated enough to take another stab at it myself and fixed the issues I was having. Experimental branch is here: https://github.com/wfraser/fuse-mt/tree/futures Would this be an improvement for...

Yep, `fuse-mt` began as just such a layer in a filesystem I made ([BackFS](https://github.com/wfraser/backfs-rs)), and I realized it was general purpose enough that it would probably be useful to others....

fixed in https://github.com/dropbox/stone/pull/299

This is because FUSE passes the mode as a `u32`, which is because the `mode_t` in `chmod(2)` is actually a 32-bit integer on some platforms (Linux at least). Not all...

So I did some experiments, and found something interesting. On Linux, while you can pass any 32-bit value to `chmod()`, at some level it gets a mask applied and the...

Looks like macOS does the same thing; even though it defines `mode_t` as `unsigned short` (16 bits), everything is masked to `0x8FFF`.