Session::mount should provide feedback on success

[Alan Somers]

Currently, Session::mount returns a future that does not complete until the file system is unmounted or an error occurs. That's fine for programs that mount one file system and do nothing else. But it's not so good for programs that do anything more. A program that mounts multiple file systems, or that does anything else, might want to know whether the mount succeeded. This is not possible with Session::mount's current signature.

To improve it, I suggest one of the following;

• Session::mount does the mount_empty_check synchronously, calls libc::mount (or equivalent) synchronously, then returns Result<dyn impl Future<...>, io::Error>. An immediate error indicates that the mount failed. A Future indicates that the mount succeeded, and the future will complete when the file system is unmounted.
• Session::mount does the mount_empty_check and libc::mount asynchronously, and returns a dyn impl Future<dyn impl Future<...>>. The outer future will complete as soon as libc::mount does. If libc::mount should succeed, then the inner future will complete when the file system is unmounted.
• Session::mount does everything asynchronously, and returns an dyn impl Future<tokio::task::JoinHandle>. The future completes after libc::mount does, and the JoinHandle completes when the file system is unmounted. This is basically the same as the second option, but more explicit.

What do you think? Do any of these options sound acceptable to you?

[Sherlock Holo]

I think the third way is better.

Currently, the inner_mount in Session::mount handles the fuse request dispatching and response replying, after creating a connection with /dev/fuse.

Maybe we can call inner_mount without .await, instead, Session::mount return an impl Future + Send + 'static, let user choose .await directly or spawn a new task.

this way can let the user know if the mount succeeds or not

[Alan Somers]

I have a PR for this ready to go, but it depends on #38.

[Sherlock Holo]

#38 is merged

[Alan Somers]

And now #39 has the fix.