Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965382AbcKKE5e (ORCPT ); Thu, 10 Nov 2016 23:57:34 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51322 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965202AbcKKE5c (ORCPT ); Thu, 10 Nov 2016 23:57:32 -0500 X-ME-Sender: X-Sasl-enc: fD8lGbOiDrYE/+pCQz3PAvRzPMigyREoR54VhE3+IvBU 1478840251 From: Nikolaus Rath To: Miklos Szeredi Cc: Andrew Gallagher , lkml , linux-fsdevel@vger.kernel.org Subject: Re: commit d7afaec0b564f0609e116f5: fuse: add FUSE_NO_OPEN_SUPPORT flag to INIT References: <87lgwrufuk.fsf@thinkpad.rath.org> Date: Thu, 10 Nov 2016 20:57:30 -0800 In-Reply-To: (Miklos Szeredi's message of "Fri, 11 Nov 2016 00:12:20 +0100") Message-ID: <87mvh6likl.fsf@vostro.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 uAB4vdjV028428 Content-Length: 1870 Lines: 47 On Nov 11 2016, Miklos Szeredi wrote: > On Thu, Nov 10, 2016 at 11:31 PM, Nikolaus Rath 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.«