Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT

[Nikolaus Rath]

On Nov 15 2016, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
> On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>
>> Yeah, I'd expect most people to do that. But FUSE file systems are often
>> a little more exotic and produce error conditions that don't match well
>> with any of the codes documented in the manpages. If there is no good
>> fit, I'd expect that most people would (as I have done so far) simply
>> pick something more appropriate from errno(3). If some of these codes
>> are forbidden (or only a subset allowed) I'd really like to document
>> this. It's not reasonable to expect every libfuse user to start browsing
>> the Linux VFS code to determine if they can use a particular error code.
>
> The library and the kernel checks for -1000 < error <= 0.  There are
> no other checks done by fuse.  However returning ENOSYS for open is
> simply wrong, it's definitely not something a sane filesystem would
> ever do.

Alright, thanks.

ENOSYS is actually treated specially for several handlers. Sometimes it
means "don't call this handler again and always fail" (getxattr et al),
sometimes it means "don't call this handler again and always succeed"
(flush, fsyncdir), and sometimes the behavior depends on the kernel
version (open).

I think I will add explicit descriptions how ENOSYS is treated to each
affected handler, and otherwise recommend to "use error codes from the
syscall manpages where possible".


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ÂTime flies like an arrow, fruit flies like a Banana.Â