Messages in this thread | | | From | Nikolaus Rath <> | Subject | Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT | Date | Thu, 10 Nov 2016 20:57:30 -0800 |
| |
On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath <Nikolaus@rath.org> 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.«
| |