On Wed, Jan 24, 2001 at 03:04:54AM -0800, Mike Smith wrote:
> I'm not sure that the v3 specification actually cares about telling the
> client "why",
It doesn't, which I think may have been a mistake.
> > For example, a UNIX "open()" call that calls an "access" vnode operation
> > couldn't, if that file is mounted over NFS, find out that the open for
> > writing is forbidden because the file system is read-only; even if
> > that's the reason, the answer you get back is probably EACCES (that's
> > what happens in the Solaris NFS, for example).
>
> This would be more or less what I'd expect. From the client's point of
> view, returning "this is a read-only filesystem" is not very useful
> anyway. What's a read-only filesystem? The NFS mount? The filesystem
> backing the mount?
I'm not sure "Permission denied" is all that useful, either; if the file
has permissions rw-r--r-- and is owned by me, "Permission denied" is a
bit of a weird error - I'd rather have the message the program shows me
or logs to a file or whatever say "Read-only file system", as that tells
me that the underlying problem is that *something* is read-only, even if
it doesn't tell me whether it's the client machine's fault for
NFS-mounting it read-only or the server's fault for {locally mounting
it, exporting it} read-only.
> I still don't really understand why the Linux code would return EROFS;
Because it's buggy.
> In the meantime, I'd also ask the Linux NFS maintainers (if they're
> listening) to consider altering their server's behaviour just for the
> sake of correctness (if it hasn't already been done subsequent to this
> relatively ancient release).
2.4.0, which is definitely not an ancient release, still appears, from
looking at the code in question, to have that buggy behavior.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
