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

Gordon Ross gordon.w.ross at gmail.com
Mon Apr 2 19:01:15 MDT 2012


Thanks, and sorry for the slow response.  The person I had working on
this had to be pulled away for something else for a while, so I'm
getting someone else to work on it.  Might take another week.

Gordon

On Mon, Apr 2, 2012 at 6:09 PM, Bryan Burgin <bburgin at microsoft.com> wrote:
> Hi Gordon,
>
> I'm touching base with you to see if you had any feedback on this per my mail below.
>
> Can you help me with "appears to be repeatedly requesting a directory listing when Windows Explorer is asked to show large directory on our server"?  Let me make sure I understand your scenario.  You have a file share.  In it, you have ~20,000 folders, either at the root or at a sub-folder.  Using Explorer, you double-click on the share (or sub-folder) to view its contents, in this case the ~20,000 folders.  I would expect a FindFirst and quite a few FindNext calls as it enumerates the contents.  Are you seeing the same FindFirst over-and-over, or a fresh FindFirst for each sub-folder (i.e., a recursive behavior)?  Or, are you right-clicking and selecting Properties to see how large a folder is?  Can you send me a trace of what's going on (at least enough of a trace to see the pattern)?  Does your SMB2 server work the same way (returns results in on-the-disk order)?  If so, do you have the same Explorer behavior when you do this with SMB2 instead of SMB"1"?  I suspect you may, as I suspect this is a shell (Explorer) behavior that wouldn't know if the underlying transport is SMB or SMB2.  Do you have any test results if the client is something other than Windows 7 (i.e., XP, Windows Vista or the Windows 8 Consumer Preview)?
>
> Bryan
>
>
> -----Original Message-----
> From: Bryan Burgin
> Sent: Wednesday, March 28, 2012 10:03 PM
> To: Gordon Ross
> Cc: cifs-protocol at samba.org; MSSolve Case Email
> Subject: [REG:112032876132836] [MS-CIFS] Trans2FindFirst/FindNext
>
> [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
>
>


More information about the cifs-protocol mailing list