Re: [PATCH] cifs: Allow nfsd over cifs

On Mon, Feb 28, 2011 at 04:58:57PM -0600, Steve French wrote:

On Mon, Feb 28, 2011 at 4:49 PM, J. Bruce Fields [off-list ref] wrote:

quoted

On Mon, Feb 28, 2011 at 03:52:41PM -0600, shirishpargaonkar@gmail.com wrote:

quoted

+static struct dentry *
+cifs_fh_to_dentry(struct super_block *sb, struct fid *fh,
+                     int fh_len, int fh_type)
+{
+     struct cifs_fid *cfid = (struct cifs_fid *)fh;
+     struct inode *inode = NULL;
+     struct cifs_fattr fattr;
+

-#endif /* CIFS_NFSD_EXPORT */
+     if (fh_type != FILEID_INO32_GEN && fh_type != FILEID_INO32_GEN_PARENT) {
+             cERROR(1, "%s: Can't handle fh type: %d", __func__, fh_type);
+             return ERR_PTR(-EINVAL);
+     }

+     if (!cfid->cino)
+             return ERR_PTR(-ESTALE);
+
+     fattr.cf_uniqueid = cfid->cino;
+     inode = iget5_locked(sb, cfid->cino, cifs_find_inode_id,
+                                     cifs_init_inode, &fattr);
+     if (IS_ERR(inode))
+             return ERR_CAST(inode);
+
+     return d_obtain_alias(inode);

Does the cifs protocol give the client a way to look up a file by inode
number (or filehandle or equivalent?).

There is a unique identifier similar to inode number returned by
various info calls,
but cifs calls use either a file handle (returned by an open) or path name to
look up metadata on a file.

Not sure whether the unique identifier can be passed in as input to an
ioctl useful here.

OK.  Then as things stand we're stuck returning ESTALE to the client
unless we happen to have the inode they're looking for in our cache?

--b.