fuse3 icon indicating copy to clipboard operation
fuse3 copied to clipboard

Problems with MountHandle

Open asomers opened this issue 1 year ago • 0 comments

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?

asomers avatar Apr 26 '24 23:04 asomers