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

[Nikolaus Rath]

On Nov 11 2016, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
> On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>> Hi Andrew,
>>
>> In commit d7afaec0b564f0609e116f5 you added a new FUSE_NO_OPEN_SUPPORT
>> flag. But as far as I can tell, the flag is simply accepted without
>> having any effect (including in libfuse).
>>
>> I tried to find related later commits, but did not find anything either.
>>
>> Am I missing something?
>
> Hmm, if fuse fs detects this flag, then it can return ENOSYS from open
> resulting in this and subsequent opens succeeding without further
> calls to userspace.    If fuse fs doesn't detect this flag, it should
> not return -ENOSYS, as that will result in the open failing, it should
> instead implement a no-op open method.

That doesn't sound like a good approach to me. That way, the file system
has to *know* that this flag has been introduced in order to behave
correctly, i.e. filesystems that predate the introduction of the flag
will suddenly behave differently.

I think the correct behavior would be to for the kernel to check if
userspace passed the flag, and treat ENOSYS specially if and only if the
flag was passed.

> Could handle this in libfuse and that would make things easier for
> filesystem implementors that would want to use this feature.  But I
> guess its use is relatively rare and so it doesn't really matter.

I agree, but it would be nice to get this sorted out properly
nevertheless. If nothing else, it will make the behavior easier to
explain.

Would you accept a patch that makes treatment of ENOSYS conditional on
userspace passing the flag (as outlined above)?


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.Â