On Tue, 3 Sep 2013 11:04:15 -0400
Jim McDonough <[email protected]> wrote:
> Since we don't get info about the number of links from the readdir
> linfo levels, stat() will return 0 for st_nlink, and in particular,
> samba re-exported shares will show directories as files (as samba is
> keying off st_nlink before evaluating how to set the dos modebits)
> when doing a dir or ls.
>
> The following patch just assumes that nlink must be 1 for files, 2 for
> directories.
>
> ---
> fs/cifs/readdir.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/fs/cifs/readdir.c
> +++ b/fs/cifs/readdir.c
> @@ -125,9 +125,13 @@ cifs_fill_common_info(struct cifs_fattr
> if (fattr->cf_cifsattrs & ATTR_DIRECTORY) {
> fattr->cf_mode = S_IFDIR | cifs_sb->mnt_dir_mode;
> fattr->cf_dtype = DT_DIR;
> + /* Fake nlink as we aren't provided this info */
> + fattr->cf_nlink = 2;
> } else {
> fattr->cf_mode = S_IFREG | cifs_sb->mnt_file_mode;
> fattr->cf_dtype = DT_REG;
> + /* Fake nlink as we aren't provided this info */
> + fattr->cf_nlink = 1;
> }
>
> if (fattr->cf_cifsattrs & ATTR_READONLY)
>
>
>
I think we'll need to do something a bit more elaborate here...
Suppose we have a hardlinked file and have previously instantiated its
inode with a link count of 2 or greater. Now you do a readdir in the
directory and find this file. Just because we didn't get any link count
information in the FIND_FIRST/NEXT response, we'll end up clobbering
the previously correct link count with the fake one here.
So, I think we need to come up with a way (a flag maybe?) in the
cifs_fattr that says "I didn't get a link count in this response, so
only fake this up if you're instantiating a new inode".
Make sense?
--
Jeff Layton <[email protected]>
--
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
