[cifs-protocol] [REG:112032876132836] [MS-CIFS] Trans2FindFirst/FindNext

[Bryan Burgin]

[dochelp to bcc]
[adding case mail and case number]

Hi Gordon,

I can help you with this.  As you suggest, a TTT may be helpful of, perhaps, the Explorer process, but that would be huge.  First, I suggest ETW/ETL logs from the file system to exclude it first.   I attached it the tool (rename t.cmd.txt to just t.cmd).  On the client, do "t clion", repro the issue, do "t clioff"" and send me the resulting t.cab output.

Thank you for the hint re: sorting.  This may be something unique to the shell (where it is causing the excessive requests).  I have additional tools to employ (perfmon and, eventually, TTT) if the T.CAB and my source review doesn't yield the answer.

Also, do you have a similar Explorer behavior with SMB2?  If not, do you also return listings in the on-the-disk ordering?

Bryan

-----Original Message-----
From: Gordon Ross [mailto:gordon.w.ross at gmail.com] 
Sent: Wednesday, March 28, 2012 1:34 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: [MS-CIFS] Trans2FindFirst/FindNext

Hi DocHelp people,

I a questions about windows client behavior involving SMB Transact2 FindFirst/FindNext, as described in MS-CIFS 2.2.6.3.1.

We have a Windows 7 (x64) client that appears to be repeatedly requesting a directory listing when Windows Explorer is asked to show large directory on our server.  The directory has about 20,000 folders.

The only obvious difference we see when comparing with a Windows server (2k8r2) is that we return the directory contents in the order found on-disk (which is in general, not sorted).

I'd appreciate suggestions on how to track down what might be the reason for the Windows client repeating the findfirst/findnext
requests as we observe.   Should we provide a TTT from the windows
client?

Thanks,
Gordon

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t.cmd.txt
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20120329/6ef38113/attachment-0001.txt>