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. --b. -- 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
