> -----Original Message----- > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > Sent: Monday, August 15, 2011 6:27 PM > To: Myklebust, Trond > Cc: linux-nfs@xxxxxxxxxxxxxxx; steved@xxxxxxxxxx; nfsv4@xxxxxxxx > Subject: Re: open() of device special files > > On Mon, Aug 15, 2011 at 06:23:36PM -0400, J. Bruce Fields wrote: > > On Mon, Aug 15, 2011 at 05:25:39PM -0400, J. Bruce Fields wrote: > > > On Mon, Aug 15, 2011 at 09:03:30AM -0700, Myklebust, Trond wrote: > > > > > -----Original Message----- > > > > > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > > > > > How is the client supposed to handle opens of device special > files? > > > > On > > > > > a 3.1-rc1-based client to a linux server over v4.0 I'm seeing > it try > > > > an > > > > > OPEN call and failing when it gets an INVAL return. > > > > > > > > > > This looks like bogus client behavior (OPEN should fail on such > > > > files), > > > > > unless the server has the error return wrong and the client's > using an > > > > > OPEN error to recover. > > > > > > > > > > If I first stat the device and then open it then it works as > expected > > > > > (the client does an open of the local device). > > > > > > > > > > I'm a bit annoyed at myself as I have a feeling we've discussed > this > > > > > before but I can't find a reference now. > > > > > > > > Hmm... NFS4ERR_INVAL means 'invalid argument', which is not the > case > > > > here; all the arguments that the client is passing to the server > are > > > > valid, however the file cannot be opened because the pathname > resolves > > > > on the server to a file of the wrong type. > > > > The long description of NFS4ERR_INVAL from rfc 3530: > > > > "Invalid argument or unsupported argument for an operation. Two > > examples are attempting a READLINK on an object other than a > > symbolic link or specifying a value for an enum field that is > > not defined in the protocol (e.g., nfs_ftype4)." > > > > So the text does recommend NFS4ERR_INVAL for the case where the > > operation doesn't make sense for the type of object given. (In the > > readlink example there's no pathname resolution, though). > > > > EINVAL seems to be used in the kernel for some such cases as well > (e.g. > > attempt to truncate a device special file). > > > > > > I can't see any other error definition that is "obviously > correct", but > > > > it looks to me as if NFS4ERR_SYMLINK might be the closest thing. > One > > > > reason is the dot-x file defines NFS4ERR_SYMLINK as meaning > "should be > > > > file/directory". > > > > And this seems more a coincidence due to vagueness resulting from the > > need for a single-line comment; the longer description is: > > > > "NFS4ERR_SYMLINK The current filehandle provided for a LOOKUP is > > not a directory but a symbolic link. Also used > > if the final component of the OPEN path is a > > symbolic link." > > > > > > The other reason is that NFS4ERR_SYMLINK should > > > > _always_ trigger the correct behaviour on a client: a fresh > lookup of > > > > the component. > > > > > > Confirmed the fix; I'll apply. > > > > Applying anyway for compatibility with existing clients, but this all > > seems a little weird. > > And the change also makes a bunch of pynfs tests fail, complaining that > various operations against incompatible types should have returned > INVAL > and not SYMLINK. > > Not that I'm convinced pynfs is correct--at the very least it should > have accepted a range of errors for those tests, I think--but anyone > else that ran pynfs against their server may have assumed it pynfs was > correct in these cases.... Pynfs is not an authoritative source for anything. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
