Hi @emitorino,
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.
zffmount
needs allow_root
or 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:
|-- /tmp
|-- 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. 