Skip to content

Problems with MountHandle #92

@asomers

Description

@asomers

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions