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 <bfields@xxxxxxxxxxxx> wrote:
> > On Mon, Feb 28, 2011 at 03:52:41PM -0600, shirishpargaonkar@xxxxxxxxx wrote:
> >> +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.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
