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.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
