[FUSE] Add ENOTSUP to ntstatus_from_errno mapping

[infeo]

Enhancement Request

Summary

Add the mapping ENOTSUP -> STATUS_INVALID_REQUEST to errno.i.

Description

WinFsp uses the function fsp_fuse_ntstatus_from_errno to map POSIX errors to Windows NTSTATUSes. By default, STATUS_ACCESS_DENIED is returned and only a subset of POSIXs error codes are mapped to different statuses (mapping is defined in errno.i).

One unmapped error code is ENOTSUP. This means fuse operations, which are implemented, but return in some/all cases ENOTSUP would always report ACCESS_DENIED to Windows, making the implementation not usable. A better mapping would be STATUS_INVALID_REQUEST, which is semantically at least vaguely familiar.

Unfortunately, this would be a breaking change.

[billziss-gh]

Looking at the Linux man page for setxattr, ENOTSUP is the error code to signify: (1) either that "extended attributes are not supported by the filesystem or are disabled", (2) or that "the namespace prefix of name is not valid".

Looking at case (1) I agree that a good choice would have been to translate ENOTSUP to STATUS_INVALID_DEVICE_REQUEST. However case (2) does not map well to STATUS_INVALID_DEVICE_REQUEST and in fact it maps better to STATUS_ACCESS_DENIED (e.g. I cannot test this right now, but I believe Linux might return ENOTSUP for extended attributes prefixed with "system.", effectively "denying access" to these attributes).

So although the ENOTSUP mapping is far from perfect, it is perhaps appropriate for a FUSE file system on Windows? After all a file system that does not implement extended attributes will not implement setxattr and WinFsp will return STATUS_INVALID_DEVICE_REQUEST. OTOH a file system that implements setxattr but wants to refuse access to certain extended attributes can return ENOTSUP as an appropriate cross-platform error code.

[infeo]

Oh, i didn't know the second meaning (of being not valid). I understand your point and since FUSE is not a Windows native API, i guess we have to deal with this deficiency.

The motivation for this ticket FR was, that we have a passthrough-filesystem, that initially implements the xattr methods, but if the underlying filesystem do not support extended attributes, returns ENOTSUP. This leads in combination with WinFsp to "access denied" errors for end users (see cryptomator/cryptomator#3207).

Actually, you also sparked a solution in our case, by prechecking the underlying filesystem for extended attribute support and configure the passthrough-fs accordingly. Thanks! (: