I doubt it was deliberate choice, but libfuse not supporting (not able to compile) on DragonFly didn't matter because DragonFly didn't have FUSE to begin with.
Actually we did have PUFFS, which can be FUSE compatible with a shim-layer, but I heard it's not working or it had never worked. The FUSE itself (i.e. kernel side) needs to be ported to DragonFly to make libfuse as well as userpace filesystems usable. libfuse currently compiles, but userspace filesystems fail on runtime as we don't have /dev/fuse which is what libfuse talks to. 2018-03-30 2:20 GMT+09:00 Carsten Mattner <[email protected]>: > On 3/28/18, Tomohiro Kusumi <[email protected]> wrote: >> libfuse compiles on dfly now. >> (requires meson/ninja as they no longer use ./configure;make) >> >> https://github.com/libfuse/libfuse/commit/72ab7172b8de822215cea644b148df5eacb8aa0a > > I suppose it is a fault in Python that it doesn't identify > dfly as one of the BSD's. Or is that a deliberate choice? > > Anyway, thanks for your effort. Now if only we had a shared, modern > filesystem between Linux and DFly, one might share a volume, > primarily on external disks.
