Trond Myklebust wrote:
On Wed, 2009-02-18 at 16:19 -0500, Jeff Garzik wrote:
I think I may have found a tiny NFSv4 client bug. What I am seeing:
1. On Linux NFS client (2.6.29-rc2), issue chown(1) to change the owner
of the file (causing SETATTR:OWNER to be issued)
2. My userland NFS server returns NFS4ERR_DENIED for the SETATTR op
3. Linux NFS client returns EIO (I/O error) to userland
That was a bit unexpected. I would have guessed EPERM, perhaps.
Jeff
I'd put this down as a server bug, as rfc 3530 really reserves the error
NFS4ERR_DENIED for the LOCK/LOCKT/LOCKU operations.
In the case of a chown(), I'd expect the server to return NFS4ERR_PERM
when failing because the caller is not root or the file owner. The
client will then correctly translate that into an EPERM...
So noted... thanks a bunch! I'll make that change.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
