On Mon, Feb 28, 2011 at 5:42 PM, J. Bruce Fields <[email protected]> wrote: > 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 <[email protected]> >> wrote: >> > On Mon, Feb 28, 2011 at 03:52:41PM -0600, [email protected] >> > 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?
Yes - that seems right and consistent with what I remember other file systems doing. IIRC LInux nfs clients handle this already. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
