[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