fuse-rs: Cleanup on terminate or prior to mount

The file system is not unmounted when the application is terminated. E.g. ctrl+c in the hello example. Attempting to run the application again (on OSX) errors out with:

mount_osxfusefs: mount point /private/tmp/test is itself on a OSXFUSE volume

I wanted to use the unmount function prior to calling mount, but it’s private. Hoping this would do the necessary cleanup to attempt unmounting orphaned file systems, and let the application happily continue running.

About this issue

Original URL
State: open
Created 8 years ago
Reactions: 2
Comments: 16 (3 by maintainers)

Most upvoted comments

I believe you need to pass them separately:

options.push(String::from("-o"))
options.push(String::from("auto_unmount"))

ylxdzsw on Sep 30, 2019

auto-unmounting is probably a bad idea. Imagine a background process that runs rsync --delete fuse/mnt/ dir/, and the fuse process crashes. If the filesystem was unmounted rsync would happily delete everything in dir/, whereas you’d get an error if it was still mounted.

kahing on Aug 14, 2017

I have fuse 2.9.5 on Linux, and it has the “-o auto_unmount” option which achieves what you want. Pass those options to the fuse::mount function, and on program exit, the filesystem will be unmounted.

wfraser on Mar 1, 2016

Performing cleanup steps with signal handlers is a fine idea, but it doesn’t eliminate the utility of a public umount function. I can think of at least two cases where it would be convenient:

fuse::mount only returns after the filesystem is unmounted: https://github.com/zargony/rust-fuse/blob/573233b236715a7bf56dd3202639aada983159c7/src/lib.rs#L374-L375
Handling the worst-case scenarios, e.g. SIGKILL provides no opportunity to cleanup. But we can still unmount the killed mount on startup.

parasyte on Feb 1, 2016

It can never be foolproof - e.g. SIGKILL doesn’t give a process any chance to react. But it sure would be nice to handle catchable signals like SIGINT (crtl-c), SIGHUP, SIGTERM.

cuviper on Jan 31, 2016