[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160709031001.GS14480@ZenIV.linux.org.uk>
Date: Sat, 9 Jul 2016 04:10:01 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Oleg Drokin <green@...uxhacker.ru>
Cc: "J. Bruce Fields" <bfields@...ldses.org>,
Jeff Layton <jlayton@...chiereds.net>,
linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of
EPERM
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.
Powered by blists - more mailing lists