> -----Original Message----- > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > Sent: Monday, August 15, 2011 11:37 AM > To: Myklebust, Trond; linux-nfs@xxxxxxxxxxxxxxx > Cc: steved@xxxxxxxxxx > Subject: open() of device special files > > 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. 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". The other reason is that NFS4ERR_SYMLINK should _always_ trigger the correct behaviour on a client: a fresh lookup of the component. Cheers 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
