* commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT
@ 2016-11-10 22:31 Nikolaus Rath
2016-11-10 23:12 ` Miklos Szeredi
0 siblings, 1 reply; 11+ messages in thread
From: Nikolaus Rath @ 2016-11-10 22:31 UTC (permalink / raw)
To: Andrew Gallagher; +Cc: Miklos Szeredi, linux-kernel, linux-fsdevel
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?
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.«
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-10 22:31 commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT Nikolaus Rath @ 2016-11-10 23:12 ` Miklos Szeredi 2016-11-11 4:57 ` Nikolaus Rath 0 siblings, 1 reply; 11+ messages in thread From: Miklos Szeredi @ 2016-11-10 23:12 UTC (permalink / raw) To: Nikolaus Rath; +Cc: Andrew Gallagher, lkml, linux-fsdevel 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. 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. Thanks, Miklos ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-10 23:12 ` Miklos Szeredi @ 2016-11-11 4:57 ` Nikolaus Rath 2016-11-11 8:43 ` Miklos Szeredi 0 siblings, 1 reply; 11+ messages in thread From: Nikolaus Rath @ 2016-11-11 4:57 UTC (permalink / raw) To: Miklos Szeredi; +Cc: Andrew Gallagher, lkml, linux-fsdevel 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 4:57 ` Nikolaus Rath @ 2016-11-11 8:43 ` Miklos Szeredi 2016-11-11 16:28 ` Nikolaus Rath 0 siblings, 1 reply; 11+ messages in thread From: Miklos Szeredi @ 2016-11-11 8:43 UTC (permalink / raw) To: Nikolaus Rath; +Cc: Andrew Gallagher, lkml, linux-fsdevel On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: > 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. ENOSYS is not a valid return value for any existing syscall. Fuse uses that fact to attach this special meaning to ENOSYS. So compatibility is not an issue here, old filesystems should never return ENOSYS from open. Thanks, Miklos ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 8:43 ` Miklos Szeredi @ 2016-11-11 16:28 ` Nikolaus Rath 2016-11-11 16:53 ` Mike Marshall 0 siblings, 1 reply; 11+ messages in thread From: Nikolaus Rath @ 2016-11-11 16:28 UTC (permalink / raw) To: Miklos Szeredi; +Cc: Andrew Gallagher, lkml, linux-fsdevel On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: > On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >> 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. > > ENOSYS is not a valid return value for any existing syscall. Fuse > uses that fact to attach this special meaning to ENOSYS. So > compatibility is not an issue here, old filesystems should never > return ENOSYS from open. Oh, I was under the impression that any FUSE handler is free to return any error it wants. Where does one have to look to determine which return values are valid? 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 16:28 ` Nikolaus Rath @ 2016-11-11 16:53 ` Mike Marshall 2016-11-11 17:27 ` Nikolaus Rath 0 siblings, 1 reply; 11+ messages in thread From: Mike Marshall @ 2016-11-11 16:53 UTC (permalink / raw) To: Nikolaus Rath; +Cc: Miklos Szeredi, Andrew Gallagher, lkml, linux-fsdevel I try to choose error codes from the appropriate man page when vfs calls into Orangefs with whatever_operations.action... there's probably better ways, like reading the vfs code and seeing what it expects <g>... -Mike On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: > On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: >> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >>> 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. >> >> ENOSYS is not a valid return value for any existing syscall. Fuse >> uses that fact to attach this special meaning to ENOSYS. So >> compatibility is not an issue here, old filesystems should never >> return ENOSYS from open. > > Oh, I was under the impression that any FUSE handler is free to return > any error it wants. Where does one have to look to determine which > return values are valid? > > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 16:53 ` Mike Marshall @ 2016-11-11 17:27 ` Nikolaus Rath 2016-11-11 17:53 ` Mike Marshall 2016-11-15 13:33 ` Miklos Szeredi 0 siblings, 2 replies; 11+ messages in thread From: Nikolaus Rath @ 2016-11-11 17:27 UTC (permalink / raw) To: Mike Marshall; +Cc: Miklos Szeredi, Andrew Gallagher, lkml, linux-fsdevel On Nov 11 2016, Mike Marshall <hubcap@omnibond.com> wrote: > On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >> On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: >>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >>>> 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. >>> >>> ENOSYS is not a valid return value for any existing syscall. Fuse >>> uses that fact to attach this special meaning to ENOSYS. So >>> compatibility is not an issue here, old filesystems should never >>> return ENOSYS from open. >> >> Oh, I was under the impression that any FUSE handler is free to return >> any error it wants. Where does one have to look to determine which >> return values are valid? >> > I try to choose error codes from the appropriate man > page when vfs calls into Orangefs with > whatever_operations.action... there's probably better > ways, like reading the vfs code and seeing what it > expects <g>... 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. 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 17:27 ` Nikolaus Rath @ 2016-11-11 17:53 ` Mike Marshall 2016-11-15 15:50 ` Nikolaus Rath 2016-11-15 13:33 ` Miklos Szeredi 1 sibling, 1 reply; 11+ messages in thread From: Mike Marshall @ 2016-11-11 17:53 UTC (permalink / raw) To: Nikolaus Rath; +Cc: Miklos Szeredi, Andrew Gallagher, lkml, linux-fsdevel There was a memorable place in the Orangefs code where the original programmer did that (pick something appropriate from errno.h) and put in a comment about how it was a more reasonable return code... When Al Viro saw it, he said it was: ... stupid. Expected error value is not EOPNOTSUPP; pardon the bluntness, but your idea of what would be less misleading doesn't matter - what matters is what the _callers_ of link(2), mknod(2), etc. are expecting. Which is to say, what does the userland code expect to get. It's outright promised in POSIX, actually. On Fri, Nov 11, 2016 at 12:27 PM, Nikolaus Rath <Nikolaus@rath.org> wrote: > On Nov 11 2016, Mike Marshall <hubcap@omnibond.com> wrote: >> On Fri, Nov 11, 2016 at 11:28 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >>> On Nov 11 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: >>>> On Fri, Nov 11, 2016 at 5:57 AM, Nikolaus Rath <Nikolaus@rath.org> wrote: >>>>> 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. >>>> >>>> ENOSYS is not a valid return value for any existing syscall. Fuse >>>> uses that fact to attach this special meaning to ENOSYS. So >>>> compatibility is not an issue here, old filesystems should never >>>> return ENOSYS from open. >>> >>> Oh, I was under the impression that any FUSE handler is free to return >>> any error it wants. Where does one have to look to determine which >>> return values are valid? >>> >> I try to choose error codes from the appropriate man >> page when vfs calls into Orangefs with >> whatever_operations.action... there's probably better >> ways, like reading the vfs code and seeing what it >> expects <g>... > > 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. > > > 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 17:53 ` Mike Marshall @ 2016-11-15 15:50 ` Nikolaus Rath 0 siblings, 0 replies; 11+ messages in thread From: Nikolaus Rath @ 2016-11-15 15:50 UTC (permalink / raw) To: Mike Marshall; +Cc: Miklos Szeredi, Andrew Gallagher, lkml, linux-fsdevel On Nov 11 2016, Mike Marshall <hubcap@omnibond.com> wrote: > There was a memorable place in the Orangefs code where > the original programmer did that (pick something appropriate > from errno.h) and put in a comment about how it was a more > reasonable return code... > > When Al Viro saw it, he said it was: > > ... stupid. Expected error value is not EOPNOTSUPP; pardon the bluntness, > but your idea of what would be less misleading doesn't matter - what matters > is what the _callers_ of link(2), mknod(2), etc. are expecting. Which is to > say, what does the userland code expect to get. It's outright promised in > POSIX, actually. I still have to see an application that, upon receiving an error from e.g. link(2), has special handlers for each of the 24 possible 24 error codes. All code that I have seen (and written) check for a few specific errors, and punts everything else to the user via strerror(). In this case, returning more specific error codes gives the user better information and doesn't violate any expectations of the application. 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-11 17:27 ` Nikolaus Rath 2016-11-11 17:53 ` Mike Marshall @ 2016-11-15 13:33 ` Miklos Szeredi 2016-11-15 15:53 ` Nikolaus Rath 1 sibling, 1 reply; 11+ messages in thread From: Miklos Szeredi @ 2016-11-15 13:33 UTC (permalink / raw) To: Nikolaus Rath; +Cc: Mike Marshall, Andrew Gallagher, lkml, linux-fsdevel On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath <Nikolaus@rath.org> 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. Thanks, Miklos ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT 2016-11-15 13:33 ` Miklos Szeredi @ 2016-11-15 15:53 ` Nikolaus Rath 0 siblings, 0 replies; 11+ messages in thread From: Nikolaus Rath @ 2016-11-15 15:53 UTC (permalink / raw) To: Miklos Szeredi; +Cc: Mike Marshall, Andrew Gallagher, lkml, linux-fsdevel On Nov 15 2016, Miklos Szeredi <mszeredi@redhat.com> wrote: > On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath <Nikolaus@rath.org> 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.« ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-11-15 15:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-10 22:31 commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT Nikolaus Rath 2016-11-10 23:12 ` Miklos Szeredi 2016-11-11 4:57 ` Nikolaus Rath 2016-11-11 8:43 ` Miklos Szeredi 2016-11-11 16:28 ` Nikolaus Rath 2016-11-11 16:53 ` Mike Marshall 2016-11-11 17:27 ` Nikolaus Rath 2016-11-11 17:53 ` Mike Marshall 2016-11-15 15:50 ` Nikolaus Rath 2016-11-15 13:33 ` Miklos Szeredi 2016-11-15 15:53 ` Nikolaus Rath
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).