> I dunno...maybe it's time to ask dochelp for clarification on what sort of > semantics we should be expecting from this field? It'll all be in MS-FSA, which is pretty simple: 2.1.5.11.27 FileStandardInformation OutputBuffer is of type FILE_STANDARD_INFORMATION, as described in [MS-FSCC] section 2.4.38. Pseudocode for the operation is as follows: ... OutputBuffer.NumberOfLinks set to the number of Link elements in Open.File.LinkList, except if Link.IsDeleted field is TRUE (that is, the number of not-deleted links to the file).<116> If OutputBuffer.NumberOfLinks is 0, set OutputBuffer.DeletePending to 1. WBN 116 has an important statement however: <116> Section 2.1.5.11.27: This algorithm is only implemented by NTFS and ReFS. The FAT, EXFAT, CDFS, and UDFS file systems always return 1. > -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx [mailto:linux-cifs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jeff Layton > Sent: Friday, July 5, 2013 6:27 PM > To: Steve French > Cc: David Disseldorp; linux-cifs@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] cifs: use sensible file nlink values if unprovided > > On Fri, 2013-07-05 at 17:12 -0500, Steve French wrote: > > Yes - I noticed that too (although with David's patch at least it is > > better). For the POSIX case for readdir we are ok, but for the > > non-posix case for readdir there is are only two infolevels, one too > > big and one too small (FILE_STANDARD_INFORMATION) that seem to > return > > nlinks so we should be setting them to default values if we can't get > > them from the server (ie if cf_attr->nlink is 0). This patch should > > fix it by catching it when we are about to update the inode to make > > sure we are putting a legal value in (I have not tested it yet). > > Thoughts on this minor followon patch? > > > > diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index 449b6cf..8329c18 > > 100644 > > --- a/fs/cifs/inode.c > > +++ b/fs/cifs/inode.c > > @@ -134,7 +134,13 @@ cifs_fattr_to_inode(struct inode *inode, struct > cifs_fattr > > inode->i_mtime = fattr->cf_mtime; > > inode->i_ctime = fattr->cf_ctime; > > inode->i_rdev = fattr->cf_rdev; > > - set_nlink(inode, fattr->cf_nlink); > > + /* number of links on a directory is at least 2, at least 1 for file */ > > + if ((fattr->cf_cifsattrs & ATTR_DIRECTORY) && (fattr->cf_nlink < 2)) > > + set_nlink(inode, 2); > > + else if (fattr->cf_nlink < 1) > > + set_nlink(inode, 1); > > + else > > + set_nlink(inode, fattr->cf_nlink); > > inode->i_uid = fattr->cf_uid; > > inode->i_gid = fattr->cf_gid; > > > > There are cases where you might see a legit i_nlink value of 0. For instance... > > client> fd = open("file", ...); > server> unlink("file"); > client> fstat(file, ...); > > ...now the server may legitimately report a link count of 0, but with this patch > we'll end up fudging it to something higher. Hence, I'm a little leery of doing > this sort of blanket overriding of cf_nlink value, especially in the case where > POSIX extensions are in force. > > I think we should only do this when we really think we can't trust this value -- > i.e. the non-POSIX case. Experience has shown that NumberOfLinks value is > not *exactly* a 1:1 match with an i_nlink value when talking to windows-y > servers. > > I dunno...maybe it's time to ask dochelp for clarification on what sort of > semantics we should be expecting from this field? > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > > -- > 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 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
