Both of these are also available from
git://linux-nfs.org/~bfields/pynfs.git
--b.
On Mon, Aug 16, 2010 at 08:38:02PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>
>
> First, the ability to deny reads is generally considered stronger than
> the ability to deny writes, so if anything should require special
> permissions it is the former.
>
> Second, this test contradicts observed Windows behavior. Testing shows
> that Windows prohits an opener without write permissions from denying
> reads. It will allow such an open, but will then also allow concurrent
> read opens, failing to enforce the DENY_WRITE.
>
> Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>
> ---
> lib/nfs4/servertests/st_open.py | 21 ---------------------
> 1 files changed, 0 insertions(+), 21 deletions(-)
>
> diff --git a/lib/nfs4/servertests/st_open.py b/lib/nfs4/servertests/st_open.py
> index 64deb9f..1e5ec70 100644
> --- a/lib/nfs4/servertests/st_open.py
> +++ b/lib/nfs4/servertests/st_open.py
> @@ -347,27 +347,6 @@ def testShareConflict1(t, env):
> "Trying to open a file with deny=WRITE "
> "that was already opened with access=WRITE")
>
> -# FRED - is this right response? or should it be allowed?
> -def testShareConflict2(t, env):
> - """OPEN with deny=write when don't have write permissions
> -
> - FLAGS: open all
> - DEPEND: MKFILE MODE
> - CODE: OPEN19
> - """
> - c1 = env.c1
> - c1.init_connection()
> - c1.create_confirm(t.code, attrs={FATTR4_MODE:0644},
> - access=OPEN4_SHARE_ACCESS_READ,
> - deny=OPEN4_SHARE_DENY_NONE)
> - c2 = env.c2
> - c2.init_connection()
> - res = c2.open_file(t.code, access=OPEN4_SHARE_ACCESS_READ,
> - deny=OPEN4_SHARE_DENY_WRITE)
> - check(res, NFS4ERR_ACCESS,
> - "Trying to deny write permissions to others when "
> - "don't have write permissions")
> -
> def testFailedOpen(t, env):
> """MULTIPLE: failed open should not mess up other clients' filehandles
>
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
