Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754292AbcKOPxK (ORCPT ); Tue, 15 Nov 2016 10:53:10 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:34280 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbcKOPxI (ORCPT ); Tue, 15 Nov 2016 10:53:08 -0500 X-ME-Sender: X-Sasl-enc: LOQ3jHQDA7xrqT597/CPQL2noddszT1HGfzLzhPHrGUR 1479225187 From: Nikolaus Rath To: Miklos Szeredi Cc: Mike Marshall , Andrew Gallagher , lkml , linux-fsdevel Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT References: <87lgwrufuk.fsf@thinkpad.rath.org> <87mvh6likl.fsf@vostro.rath.org> <87mvh6j803.fsf@thinkpad.rath.org> <87d1i2j5af.fsf@thinkpad.rath.org> Date: Tue, 15 Nov 2016 07:53:06 -0800 In-Reply-To: (Miklos Szeredi's message of "Tue, 15 Nov 2016 14:33:22 +0100") Message-ID: <87a8d0agf1.fsf@thinkpad.rath.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAFFrFGl029128 Content-Length: 1666 Lines: 38 On Nov 15 2016, Miklos Szeredi wrote: > On Fri, Nov 11, 2016 at 6:27 PM, Nikolaus Rath 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.«