From owner-freebsd-stable Tue Jan 23 19:35: 4 2001 Delivered-To: freebsd-stable@freebsd.org Received: from emma1.emma.line.org (p3EE3CBDA.dip.t-dialin.net [62.227.203.218]) by hub.freebsd.org (Postfix) with ESMTP id 5D57A37B400 for ; Tue, 23 Jan 2001 19:34:46 -0800 (PST) Received: by emma1.emma.line.org (Postfix, from userid 500) id 8FE5BA2001; Wed, 24 Jan 2001 04:34:36 +0100 (CET) To: Guy Harris Cc: Linux NFS mailing list , FreeBSD Stable Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <20010123111005.D344@quadrajet.flashcom.com> In-Reply-To: <20010123111005.D344@quadrajet.flashcom.com> From: Matthias Andree Date: 24 Jan 2001 04:34:36 +0100 Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (Perhaps it would've been better had the V3 protocol specified that > either 0 or an NFS3ERR_xxx value be supplied for each of the permission > bits checked, although that raises the question of whether any server > would, say, allow read access and allow write access but disallow > simultaneous read/write access.) No, the plan is simple. In the ACCESS call, the client asks if it has a certain set of permissions, the sender weeds the actions the client may not take at the moment of the ACCESS call, and returns a possibly stripped-down set of allowed actions (which may then change later). There's nothing wrong with this approach. Plus, I don't expect that ACCESS has context-sensitive semantics (like: allow each of read or write on its own, but deny read-write), or I may have overlooked the explicit statement it has these semantics. > One might also consider it a FreeBSD client problem that it can't cope > with this, if the Solaris client can, No, FreeBSD just passed the error on to the application. Keeping it simple and refraining from workarounds is a virtue. > although that one might be a weaker claim (i.e., the Linux server is > arguably violating the spec, whilst the FreeBSD client is merely > apparently not doing as good a job of coping with servers violating > the spec as the Solaris client is, in this case). Tolerance (FreeBSD kludging around broken Linux server) may be good for making these systems cooperate, but fixing the problem rather than its symptoms is the right way to go. Until then, mount_nfs -2 is a viable alternative for many, if not most, FreeBSD users. -- Matthias Andree To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message