No problem - I had considered sending a “push”, but thought it might take longer with classic requests.
Thank you for spending your time to answer my request.
It is theoretically possible to set the mountpoint to one of the paths you mentioned but:
- the mountpoint is determined by the user, not by me. That happens with an argument (-m).
- unfortunately this would not solve the basic problem.
user_allow_other to allow a nested mount (
user_allow_other would provide a maximum amount of flexibility here, but if that’s what it comes down to, I would of course let myself be traded down to
allow_root. ). This is (to my knowledge) unfortunately not supported by the
fuse-control snap interface (or any other snap interface I know of - but if there is one, I am of course very open to suggestions ).
I’ll elaborate a bit more to make the actual problem more understandable:
The tool is in fact used to allow the user to “mount” files in this file format. If the tool were to simply mount such files via FUSE in order to then process them myself, I would immediately agree with you and be able to restrict myself to one of the paths mentioned above. However, since the purpose of the program is to allow the user to mount to the path of their choice, your suggestion unfortunately directly counters the actual purpose of the program.
With this we have described the first problem.
The second problem: You can consider zff as a kind of container system, which contains a different set of subcontainers (internally called objects). zffmount creates an overlay filesystem and mounts it via FUSE. Into this overlay file system, the respective objects are then mounted into a folder located in the overlay file system with the appropriate object file system for the object type via FUSE. Let’s say we have a zff container with three objects and I would mount it to /tmp/mount using zffmount, the folder structure would look like this:
|-- mount/ (overlay filesystem)
|-- object_01 (content of the first object with appropriate filesystem)
|-- object_02 (content of the second object with appropriate filesystem)
|-- object_03 (content of the third object with appropriate filesystem)
From my perspective, there is a gap here between what interfaces are offered and what is/will be approved for classic mode. I don’t see zffmount falling into either the supported or unsupported category of the classic review process right now. But of course that’s just my point of view.