Support OSXFUSE fssubtype

[tv42]

https://github.com/osxfuse/osxfuse/wiki/Mount-options#fssubtype

The Linux subtype option takes an arbitrary identifying string, the OSXFUSE option takes an integer referring to one of the built-in definitions (see /Library/Filesystems/osxfuse.fs/Contents/Info.plist). I'm not sure it makes sense to try to unify them.

[tv42]

@presotto Would a separate func OSXFSSubType(i uint32) MountOption make sense to you? I'd happily take a pull request for that ;)

(Evidence that osxfuse treats it as uint32: common/fuse_mount.h:36: uint32_t fssubtype; // file system sub type id)

[tv42]

I would also very much welcome somebody doing research on OSXFUSE/OS X and figuring out whether the FSPersonalities really need to be read from that plist file, or whether that's just a MacFUSE legacy with no reason for OSXFUSE to not support Linux-style subtype=STRING.

I find Ben, the OSXFUSE upstream, very amenable to changes once you can justify them sufficiently; a lot of the places where OSXFUSE deviates from Linux FUSE are from before his era, and he's cleaned up plenty of instances already.

[tv42]

One thing that comes to mind is that the linux convention is heavily in the style of ext4, xfs, btrfs and friends: lowercase single word. The OS X convention seems to be "user-friendly phrase":

                <key>Beagle</key>
                <dict>
                        <key>FSName</key>
                        <string>Beagle File System (OSXFUSE)</string>
                        <key>FSSubType</key>
                        <integer>9</integer>
                </dict>

So even if the number dance would not be needed, perhaps this would need to be SubtypeName or some other wording, where at some point Linux and such could also make use of a friendlier string somewhere.

Also, what's the distinction between Beagle / Beagle File System (OSXFUSE) there. Are both visible? That sounds like the string replacement for 9 would be two mount options.

[presotto]

I agree. Forget my change for now. If I need it, I'll give you back a
change with a SubTypeName or some such. Mostly I was trying to make the
option match the usage message from the osxfuse mount helper, i.e., I was
being anal.

And next time I won't use the github desktop tool to do a push until I
understand it better. First time I tried it and I didn't expect the paths
to get changed.

On Mon, Jun 6, 2016 at 12:59 PM, Tv [email protected] wrote:

One thing that comes to mind is that the linux convention is heavily in
the style of ext4, xfs, btrfs and friends: lowercase single word. The OS
X convention seems to be "user-friendly phrase":

            <key>Beagle</key>
            <dict>
                    <key>FSName</key>
                    <string>Beagle File System (OSXFUSE)</string>
                    <key>FSSubType</key>
                    <integer>9</integer>
            </dict>

So even if the number dance would not be needed, perhaps this would need
to be SubtypeName or some other wording, where at some point Linux and
such could also make use of a friendlier string somewhere.

Also, what's the distinction between Beagle / Beagle File System (OSXFUSE)
there. Are both visible? That sounds like the string replacement for 9
would be two mount options.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#140 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AFM2PSD8PTrBnVa0G5-qCbDKxkQiNL89ks5qJHwKgaJpZM4IvM-G
.

[tv42]

Heads up: the future of macOS support is in danger. If you care about FUSE on macOS, please encourage talented developers to pick up maintenance of the open source project. See #224

[tv42]

macOS support has been removed. If somebody wants to pick up maintaining an open source macOS FUSE, or wants to fund supporting the proprietary continuation of OSXFUSE, please get in touch.
#224