Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root

Jim Rees <rees@umich.edu> Mon, 17 May 2004 11:39 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15289 for <nfsv4-archive@odin.ietf.org>; Mon, 17 May 2004 07:39:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgNT-0005Sn-T8 for nfsv4-archive@odin.ietf.org; Mon, 17 May 2004 07:33:52 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HBXpBC020997 for nfsv4-archive@odin.ietf.org; Mon, 17 May 2004 07:33:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgIh-0004ct-LE for nfsv4-web-archive@optimus.ietf.org; Mon, 17 May 2004 07:28:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14430 for <nfsv4-web-archive@ietf.org>; Mon, 17 May 2004 07:28:55 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPgIh-0007MU-2H for nfsv4-web-archive@ietf.org; Mon, 17 May 2004 07:28:55 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPgHi-00073V-00 for nfsv4-web-archive@ietf.org; Mon, 17 May 2004 07:27:54 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPgGn-0006ks-00 for nfsv4-web-archive@ietf.org; Mon, 17 May 2004 07:26:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPgDx-0003oK-L1; Mon, 17 May 2004 07:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPg89-00030I-F6 for nfsv4@optimus.ietf.org; Mon, 17 May 2004 07:18:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13890 for <nfsv4@ietf.org>; Mon, 17 May 2004 07:18:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPg88-0003rv-ST for nfsv4@ietf.org; Mon, 17 May 2004 07:18:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPg7D-0003Wz-00 for nfsv4@ietf.org; Mon, 17 May 2004 07:17:03 -0400
Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx with esmtp (Exim 4.12) id 1BPg6A-0003Bj-00 for nfsv4@ietf.org; Mon, 17 May 2004 07:15:58 -0400
Received: from citi.umich.edu (dsl093-001-248.det1.dsl.speakeasy.net [66.93.1.248]) by citi.umich.edu (Postfix) with ESMTP id 1E073207E2 for <nfsv4@ietf.org>; Mon, 17 May 2004 07:15:58 -0400 (EDT)
Subject: Re: [nfsv4] FYI: Readdir not allowed on NFS pseudo root
To: nfsv4@ietf.org
From: Jim Rees <rees@umich.edu>
In-Reply-To: Spencer Shepler, Sun, 16 May 2004 20:44:56 CDT
Message-Id: <20040517111558.1E073207E2@citi.umich.edu>
Sender: nfsv4-admin@ietf.org
Errors-To: nfsv4-admin@ietf.org
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/nfsv4/>
X-Original-Date: Mon, 17 May 2004 07:15:57 -0400
Date: Mon, 17 May 2004 07:15:57 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

  Seems like the server would return an "empty" response for READDIR
  on this special server.

But that would be wrong too.  That would imply the directory is empty.  I
can imagine a client that would get very confused by this.  Suppose, for
example, the client caches directory contents after a successful READDIR,
and uses the cached copy for subsequent lookups.  I think NFS4ERR_ACCESS is
the only acceptable response.

  This also implies that clients must use LOOKUP to traverse the
  server's namespace on things like traditional mount operations that
  a client would do.

Yes.  The client must be prepared for this anyway.  In fact, the client
probably can't tell and doesn't care whether it's in a pseudo-fs or a real
one.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4