Update to use FUSE kernel ABI 7.19 which opens up the possibility to support more desired features like better optimization, ioctl and polling/notifications. This will raise the requirements to FUSE 2.9.1 or later on Linux and OSXFUSE 3.0.0 or later on macOS. There are even newer ABI versions, but 7.19 seems to be the one most commonly supported by various systems.

cargo build produce empty target/debug/examples/ directory.

Manual compilation also fails:

$  rustc    -L target/debug  examples/hello.rs  
examples/hello.rs:3:1: 3:19 error: found possibly newer version of crate `log` which `fuse` depends on
examples/hello.rs:3 extern crate fuse;
                    ^~~~~~~~~~~~~~~~~~
examples/hello.rs:3:1: 3:19 note: perhaps this crate needs to be recompiled?
examples/hello.rs:3 extern crate fuse;
                    ^~~~~~~~~~~~~~~~~~
examples/hello.rs:3:19: 3:19 note: crate `log` path #1: /home/vi/home/rust/prefix/lib/rustlib/i686-unknown-linux-gnu/lib/liblog-4e7c5e5c.rlib
examples/hello.rs:3:19: 3:19 note: crate `log` path #2: /home/vi/home/rust/prefix/lib/rustlib/i686-unknown-linux-gnu/lib/liblog-4e7c5e5c.so
examples/hello.rs:3:19: 3:19 note: crate `fuse` path #1: /home/vi/home/rust/rust-fuse/target/debug/libfuse-c61beed3b50079b8.rlib
error: aborting due to previous error

I think there should also be a fusexmp or bindfs-like example. This is both useful as a reference of Rust's filesytem features and as a basis for new FUSE programs.

I've added some structure to support integration tests. Right now there are only a few, which exercise code similar to the ones in the examples directory, but the idea is to add more to cover different usage patterns that we intend to support.

Because it's a bit more hazardous to actually mount filesystems, I figured these needed to be a different target and not part of make check.

I tried to figure out how to actually use, rather than copy, the code in the examples dir for the integration tests, but I couldn't see how without adding integration test code to the examples themselves, which would then make the code files less useful as examples of normal use.

Right now, the "null-example" test does not work correctly under OS X--it passes its tests, but then fails to stop its background task and gets killed by the wrapper script after timing out. This is due to #7.

In reply to your comment on reddit in which you explained why you don't spawn a new task for each operation:

First I planned to dispatch every operation into separate tasks, but then I realized that this might not be always desirable. One idea of Rust is to prevent waiting/locking at all by grouping access to one resource in a single task. Most of the filesystem operations deal with metadata that manage inodes. They could easily be done in a single task since they'd require exclusive access to these metadata anyway. Operations that deal with actual data (read/write) are candidates to be parallelized, I think. However I don't have any benchmarks on this idea yet.

The metadata, as well as the underlying data, may live across a network somewhere, which means any operation might be both slow and parallelizeable. So I think all of operations should be able to run concurrently, not just read and write. But your point about internal inode mappings still stands, so I agree that it shouldn't force a new task for every operation.

So here's another idea. For simplicity, let me pick readlink as the example--the signature would change from this:

fn readlink (&mut self, _ino: u64) -> Result<~str, c_int>

to this:

fn readlink (&mut self, _ino: u64,
             handle: ReplyHandle<Result<~str, c_int>>)

(I'm not sure I like the name "ReplyHandle" but am at a loss for a better one.) You could implement it synchronously like this:

impl FileSystem for SingleTaskFS {
    fn readlink(&mut self, ino: u64,
                handle: ReplyHandle<Result<~str, c_int>>) {
        let s:~str = (/*get the result here...*/);
        handle.reply(Ok(s));
    }
}

or asynchronously like this:

impl FileSystem for MultiTaskFS {
    fn readlink(&mut self, ino: u64,
                handle: ReplyHandle<Result<~str, c_int>>) {
        do task().spawn_with(handle) |handle| {
            let s:~str = (/*get the result here...*/);
            handle.reply(Ok(s));
        }
    }
}

The reply method of the handle would take by-value self, and the handle would be sendable but not copyable. So the compiler would ensure that the operation could not reply multiple times, and that only correctly typed replies could be sent for each operation. It could not enforce at compile time that the code for the operation always explicitly provides a reply, but the handle could implement Drop so as to automatically provide an error back to FUSE if it falls out of scope when no reply was provided.

This pattern could also allow data to be passed out of read without copying the data--the handle passed to read could take an enum with many forms, including a borrowed slice, another file descriptor, or even (unsafely) an iovec.

I plan to try this out myself, but I'm leaving this issue here in advance, in case you had any thoughts on the general idea before I've fleshed out all the specifics.

Current rust-fuse doesn't have blksize field in fuse_attr struct.

Is this a bug?

struct fuse_attr {
        __u64   ino;
        __u64   size;
        __u64   blocks;
        __u64   atime;
        __u64   mtime;
        __u64   ctime;
        __u32   atimensec;
        __u32   mtimensec;
        __u32   ctimensec;
        __u32   mode;
        __u32   nlink;
        __u32   uid;
        __u32   gid;
        __u32   rdev;
        __u32   blksize;
        __u32   padding;
};

This implements something close to the structures described in the comments of #1. The main difference in the filesystem operation signatures from what was discussed before is that the type parameter is on the Request, not the Reply.

There were more changes needed to make concurrent filesystem operations actually work. Along with that I rearranged the code a bit, which I hope leaves it in a state that makes sense. It started when I needed to repurpose Request, and thus moved the dispatch fn to session (which makes more sense--it was mutating the session object anyway.) Then it seemed odd that some of the channel-handling code was in session, so I moved it to channel with the rest of it.

I split this into two commits so that if you look at the second commit, you can see the actual changes, as opposed to this being hidden among the moves.

Hi,

Thanks for making and maintaining rust-fuse! The library fills a very important slot in the ecosystem.

I'm currently trying to implement the write support for my file system but there is something that I don't understand. I am working on macOS 10.13.

If I issue an append command:

$ echo "test" >> my_file.txt

where my_file.txt is an existing, non-empty file in my file system, I see that the file will be opened with flags O_WRONLY. I don't see O_APPEND being passed. Is that correct?

The call to open is followed by a call to write with offset 0.

I was expecting either O_APPEND being passed to open and then write being done at offset 0, or O_APPEND isn't passed, and then write is done with offset equal to the current length of the file.

I found some documentation about writeback caches on Linux, where the append mode is handled by the kernel, but no reference to this on macOS.

Do you have any ideas about this issue? It's entirely possible that I'm misunderstanding all the calls.

Thanks!

Would it be a good idea to patch to this? That would be a breaking change to fuse::FileAttr.

(The need would be reduced significantly if Timespec implemented From)

As of rustc version “rustc 0.13.0-nightly (42deaa5e4 2014-12-16 17:51:23 +0000)” the library fails to compile. The cause appears to be the removal of proc():

$ cargo build
   Compiling fuse v0.2.0 (file:///home/phg/src/rust-dev/rust-fuse-git)
src/reply.rs:27:34: 27:38 error: obsolete syntax: the `proc` type
src/reply.rs:27     fn new (unique: u64, sender: proc(&[&[u8]]):Send) -> Self;
                                                 ^~~~
note: use unboxed closures instead

I've incorporated @ebfe's #22 and @glittershark's #24, then added a few warning and deprecation fixes of my own. I also fleshed out Cargo.toml a bit more and updated .travis.yml with native rust support.

If you create a BackgroundSession object and destroy it, the background task running the real session won't actually terminate right away on OS X. It seems that the libc::read call is not interrupted by the call to fuse_unmount_compat22, so it won't kill the background task until something else tries to use the filesystem. Unmounting it externally (by running "umount" in another shell) does not appear to have this problem--it interrupts the read call right away. The problem also doesn't seem to happen on Linux.

This changes the naming convention. The library follows same naming convention as Linux libfuse. The build does not need to make exception for Mac OS target

With target x86_64-unknown-linux-musl

cargo build --jobs 10 --examples --target x86_64-unknown-linux-musl
   Compiling fuse-sys v0.4.0-dev (/home/teawater/fuse-rs/fuse-sys)
   Compiling regex v1.5.5
error: failed to run custom build command for `fuse-sys v0.4.0-dev (/home/teawater/fuse-rs/fuse-sys)`

Caused by:
  process didn't exit successfully: `/home/teawater/fuse-rs/target/debug/build/fuse-sys-b1102c79a2fb4df4/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=FUSE_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_x86_64-unknown-linux-musl
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_x86_64_unknown_linux_musl
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-musl
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_musl
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-musl
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_musl
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  pkg-config has not been configured to support cross-compilation.

  Install a sysroot for the target platform and configure it via
  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
  cross-compiling wrapper for pkg-config and set it via
  PKG_CONFIG environment variable.
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', fuse-sys/build.rs:12:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Without x86_64-unknown-linux-musl can build.

cargo build --jobs 10 --examples
   Compiling cfg-if v1.0.0
   Compiling quick-error v1.2.3
   Compiling regex-syntax v0.6.25
   Compiling thread-scoped v1.0.2
   Compiling fuse-abi v0.4.0-dev (/home/teawater/fuse-rs/fuse-abi)
   Compiling termcolor v1.1.3
   Compiling libc v0.2.121
   Compiling memchr v2.4.1
   Compiling log v0.4.16
   Compiling fuse-sys v0.4.0-dev (/home/teawater/fuse-rs/fuse-sys)
   Compiling humantime v1.3.0
   Compiling aho-corasick v0.7.18
   Compiling atty v0.2.14
   Compiling fuse v0.4.0-dev (/home/teawater/fuse-rs)
   Compiling regex v1.5.5
   Compiling env_logger v0.6.2
    Finished dev [unoptimized + debuginfo] target(s) in 6.31s

I'm coming from the redox-os project which relies on fuse to build redoxfs.

Steps to reproduce:

install fuse3, clone fuse-rs, run cargo build.

error: failed to run custom build command for `fuse v0.3.1`

Caused by:
  process didn't exit successfully: `/home/liam/repos/redoxfs/target/debug/build/fuse-af7cecec4946dbaf/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=FUSE_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=FUSE_STATIC
  cargo:rerun-if-env-changed=FUSE_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"fuse\" \"fuse >= 2.6.0\"", output: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Package fuse was not found in the pkg-config search path.\nPerhaps you should add the directory containing `fuse.pc'\nto the PKG_CONFIG_PATH environment variable\nPackage 'fuse', required by 'virtual:world', not found\nPackage 'fuse', required by 'virtual:world', not found\n" } }', /home/liam/.cargo/registry/src/github.com-1ecc6299db9ec823/fuse-0.3.1/build.rs:10:76
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

how to fix: When I switch the build.rs to search for fuse3 instead of fuse, the package compiles perfectly.

The cask osxfuse is still on version 3.x of the library. This is pretty outdated, since there's already a 4.0.5. I updated the README to use another cask called macfuse which corresponds to the newer version of osxfuse. It seems that while moving up in versions, they also changed the library package name to "fuse" as on other platforms, instead of the previous "osxfuse". Hence, I also updated the build.rs file to be able to build on the newer version.

Instead of just changing the name, we could also implement a check for both names: osxfuse and fuse when building on MacOS. I am happy to adapt this PR if you want. With this new library version, the crate builds perfectly fine on the new Apple Silicon MacBooks 👍