mount.zfs argument order breaks on POSIX-conforming getopt

[leahneukirchen]

The mount.zfs helper program uses getopt(3) to parse its arguments. mount.zfs is called by util-linux with the non-standard order of <spec> <mountpoint> -o <options> which other tools like mount.nfs or sshfs explicitly expect. (This is specified in EXTERNAL HELPERS in util-linux mount(8).)

This is not a problem on glibc since GNU getopt(3) will reorder the arguments. However, alternative libc such as musl libc (or glibc with $POSIXLY_CORRECT set) will not permute argv and fail to parse the -o <options>.

I see two options here:

• force the first two arguments to be <device> <mountpoint> and use getopt on the rest.
• use getopt_long instead, which permutes arguments on glibc and musl.

The latter option has been implemented as a patch by Void Linux: https://github.com/voidlinux/void-packages/commit/0203a5aa0f26bb0ef334e09c8736f35275d06e8f

[behlendorf]

Normally I'd suggest avoiding the use of getopt_long() is ZFS since it's a GNU extension and one of our goals is to keep the code as portable as possible. However, mount.zfs is already one of the few bits of Linux specific bit of code so I don't see any harm in updating it as you suggest. Can you open a PR against zfsonlinux/zfs with the voidlinux/void-packages@0203a5a fix. That way we can get it tested, reviewed, and merged.