Date: Thu, 25 Jan 2001 15:40:06 -0500 (EST) From: Eric Werme USG <werme@wasted.zk3.dec.com> To: Mike Smith <msmith@freebsd.org>, Linux NFS mailing list <nfs@lists.sourceforge.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Cc: Guy Harris <gharris@flashcom.net> Subject: Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export Message-ID: <200101252040.PAA0000803167@anw.zk3.dec.com>
next in thread | raw e-mail | index | archive | help
> At least from looking at the Linux 2.2.18 code, if you get EROFS back
> from the Linux server, the actual set of access bits you get back won't
> have the right bits set; "nfsd_access()" just jumps to "out:" if it gets
> a "read-only file system" error, and that doesn't set "*access" to the
> result.
Umm, either I'm reading your post wrong, or you've glitched on your
recall of the protocol.
If you get EROFS back from ACCESS, you won't get access bits:
/*
* The following union defines the results from invoking the
* procedure ACCESS.
*/
struct ACCESS3resok {
post_op_attr obj_attributes;
uint32 access; /* bit mask - see above */
};
struct ACCESS3resfail {
post_op_attr obj_attributes;
};
union ACCESS3res switch (nfsstat3 status) {
case NFS3_OK:
ACCESS3resok resok;
default:
ACCESS3resfail resfail;
};
If status == NFS3ERR_ROFS, then you get ACCESS3resfail which does not
have the bit mask that is only returned as part of ACCESS3resok.
Folks, I think we've beaten this dead molehill into a mountain.
What's going to happen when someone finds a big problem?
-Ric Werme
--
Eric (Ric) Werme | werme@zk3.dec.com
Compaq Computer Corp.
>>>> http://people.ne.mediaone.net/werme/h8dcyf.html <<<<
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?200101252040.PAA0000803167>