Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with MountHandle #92

Open
asomers opened this issue Apr 26, 2024 · 0 comments
Open

Problems with MountHandle #92

asomers opened this issue Apr 26, 2024 · 0 comments

Comments

@asomers
Copy link
Contributor

asomers commented Apr 26, 2024

PR #81 introduced new behavior to MountHandle. When it is dropped, it will now attempt to unmount the file system. But this new behavior introduced new problems:

  • Previously there was little reason for a file system to store the MountHandle. If the file system immediately drops it, then after upgrading to fuse3 0.7.1 it will generate a error=init stage get destroy result error during init. You could help users avoid this situation by adding a #[must_use] to MountHandle.
  • If MountHandle gets dropped during init, it actually won't even unmount the file system
  • It isn't necessary. FileSystem::destroy already gets called on unmount. For example, if you do sudo umount /path/to/fs from the command line.

IMHO MountHandle is unnecessary. If the developer wants to automatically unmount when closing their daemon, then they can easily call libc::unmount (or a wrapper) during the drop method of their Filesystem implementation. Plus, MountHandle::unmount is also unnecessary, or at least unnecessarily complicated. Again, libc::unmount would suffice. The daemon would still get the FUSE_DESTROY message. Basically, my philosophy is that unmounting should originate with the operating system and the daemon should respond to that. That's the way the fuse protocol was designed.

Or is there something I'm not seeing? Maybe some other motivation for that PR? I only use FreeBSD. Does FUSE_DESTROY not get send in some circumstances?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant