From: "J. Bruce Fields" <bfields@fieldses.org>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Jeff Layton <jlayton@poochiereds.net>,
linux-nfs@vger.kernel.org,
Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM
Date: Wed, 13 Jul 2016 15:00:29 -0400 [thread overview]
Message-ID: <20160713190029.GB10459@fieldses.org> (raw)
In-Reply-To: <67C35F5E-7CB0-4CE9-998F-D9871E0DAF81@linuxhacker.ru>
On Fri, Jul 08, 2016 at 11:41:41PM -0400, Oleg Drokin wrote:
>
> On Jul 8, 2016, at 11:10 PM, Al Viro wrote:
>
> > On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:
> >
> >> I wonder if people just accept that "NFS is just weird" and code in workarounds,
> >> where as with Lustre we promise (almost) full POSIX compliance, and also came much later
> >> so people are just seeing that "this does not work" and complain more loudly?
> >
> > To quote POSIX: "If more than one error occurs in processing a function call,
> > any one of the possible errors may be returned, as the order of detection is
> > undefined." (from System Interfaces: General Information: 2.3 Error Numbers)
> >
> > And regarding mkdir(2) it has
> > [EACCES]
> > Search permission is denied on a component of the path prefix, or write
> > permission is denied on the parent directory of the directory to be created.
> > [EEXIST]
> > The named file exists.
> > among the error conditions. In situations when both apply, the implementation
> > is bloody well allowed to return either. It might be nicer to return EEXIST
> > in such cases, for consistency sake (if another thread does stat() on the
> > pathname in question just as you are about to call mkdir(2), you will get
> > EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
> > please do not bring POSIX compliance as an argument. It's a QoI argument and
> > nothing beyond that.
>
> Ok, I see.
> Thanks.
>
> Bruce, do you want the patch resubmitted with a rewritten commit message,
> or do you think it's best to just drop it them?
Other things being equal I still agree with you that there'd be
advantages to being more consistent, so a changelog update would be
fine.
--b.
next prev parent reply other threads:[~2016-07-13 19:01 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-08 1:47 [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM Oleg Drokin
2016-07-08 11:02 ` Jeff Layton
2016-07-08 15:14 ` Oleg Drokin
2016-07-08 15:53 ` Jeff Layton
2016-07-08 15:59 ` Oleg Drokin
2016-07-08 16:17 ` Jeff Layton
2016-07-08 16:28 ` Oleg Drokin
2016-07-09 2:52 ` Al Viro
2016-07-09 2:58 ` Oleg Drokin
2016-07-09 3:13 ` Al Viro
2016-07-08 16:04 ` J. Bruce Fields
2016-07-08 16:16 ` Oleg Drokin
2016-07-08 20:49 ` J. Bruce Fields
2016-07-08 21:47 ` Oleg Drokin
2016-07-09 3:10 ` Al Viro
2016-07-09 3:41 ` Oleg Drokin
2016-07-13 19:00 ` J. Bruce Fields [this message]
2016-07-08 20:54 ` J. Bruce Fields
2016-07-08 21:53 ` Oleg Drokin
2016-07-21 20:34 ` J. Bruce Fields
2016-07-21 20:37 ` Oleg Drokin
2016-07-22 1:57 ` J. Bruce Fields
2016-07-22 6:35 ` Oleg Drokin
2016-07-22 10:55 ` J. Bruce Fields
2016-07-22 15:13 ` Oleg Drokin
2016-07-22 17:48 ` J. Bruce Fields
2016-07-22 17:48 ` [PATCH 1/7] nfsd: Make creates return EEXIST instead of EACCES J. Bruce Fields
2016-07-22 17:48 ` [PATCH 2/7] nfsd: remove redundant zero-length check from create J. Bruce Fields
2016-07-22 17:48 ` [PATCH 3/7] nfsd: remove redundant i_lookup check J. Bruce Fields
2016-07-24 0:22 ` Al Viro
2016-07-24 12:10 ` J. Bruce Fields
2016-07-24 14:23 ` Al Viro
2016-07-24 20:21 ` J. Bruce Fields
2016-07-22 17:48 ` [PATCH 4/7] nfsd: reorganize nfsd_create J. Bruce Fields
2016-07-22 17:48 ` [PATCH 5/7] nfsd: remove unnecessary positive-dentry check J. Bruce Fields
2016-07-22 17:48 ` [PATCH 6/7] nfsd: clean up bad-type check in nfsd_create_locked J. Bruce Fields
2016-07-22 17:48 ` [PATCH 7/7] nfsd: drop unnecessary MAY_EXEC check from create J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160713190029.GB10459@fieldses.org \
--to=bfields@fieldses.org \
--cc=green@linuxhacker.ru \
--cc=jlayton@poochiereds.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).