Date: 24 Jan 2001 04:34:36 +0100 From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> To: Guy Harris <gharris@flashcom.net> Cc: Linux NFS mailing list <nfs@lists.sourceforge.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <m3r91t8vxv.fsf@emma1.emma.line.org> In-Reply-To: <20010123111005.D344@quadrajet.flashcom.com> References: <20010123015612.H345@quadrajet.flashcom.com> <20010123162930.B5443@emma1.emma.line.org> <20010123111005.D344@quadrajet.flashcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3r91t8vxv.fsf>