Re: [PATCH] cifs: use sensible file nlink values if unprovided

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2013-07-06 at 00:13 +0000, Tom Talpey wrote:
> > 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.
> 
> 

Thanks! I probably should have read the spec before crying to dochelp ;)

I think that makes sense. So what we probably want to do is something
like (pseudocode):

if (nlink == 0) {
	if (directory)
		nlink = 2;
	else if (regular file && !delete pending)
		nlink = 1;
}

...IOW, leave it at 0 if delete pending is set. It would be preferable
to encapsulate this logic in a function too and call it from all of the
places where we want to fake up this value.

readdir is tricky since none of the non-POSIX infolevels seem to return
a NumberOfLinks value or a DeletePending flag. Probably best to just
fake them up as best we can and hope that a later getattr fetches the
correct value. If the dirent didn't have a link count of at least 1,
then it presumably wouldn't be visible to a FIND_* call.

Note too that this does mean that the server that David is trying to
work around is arguably broken. It's probably reasonable to go ahead and
work around it since we need to do something similar for the readdir
case anyway, but it would be best to have them fix their server as well.

-- 
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




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux