[Samba] Friendly Reminder: Would you please comment on my findings?

[Jeremy Allison]

On Fri, Aug 18, 2017 at 10:54:29PM +0200, awl1 wrote:
> Hello Andrew,
> 
> many thanks for joining this discussion! :-)
> 
> Am 18.08.2017 um 21:46 schrieb Andrew Bartlett:
> >I do realise you are in between a rock and a hard place.  You have
> >identified an interesting issue, triggered by a massive protocol change
> >(so not able to be bisected down to a regression) that requires
> >significant work to understand and may or not be possible to resolve.
> Note that I have tracked down the issue to what I believe to be the
> root cause, and the root cause is NOT an issue in Samba, but an
> issue with Microsoft's SMB2/SMB3 client that uses completely
> inefficient SMB2_FIND_ID_BOTH_DIRECTORY_INFO requests in SMB2/3 as
> opposed to efficient FIND_FIRST2 requests in SMB1:
> 
> The main parts of my analysis of the issue are contained here:
> 
> https://lists.samba.org/archive/samba/2017-July/209749.html
> https://lists.samba.org/archive/samba/2017-July/209750.html
> https://lists.samba.org/archive/samba/2017-July/209751.html
> 
> Just citing key findings for your reference:
> 
> In SMB1, the Windows client executes one FIND_FIRST2 Request for
> each file to be copied (i.e. in my scenario, ~ 1000 requests)
> returning STATUS_NO_SUCH_FILE every time before actually
> creating/writing to the file.
> 
> When looking at the same file in the SMB2 3.1.1, the Windows client
> issues a different Find operation (SMB2_FIND_ID_BOTH_DIRECTORY_INFO
> with Pattern "*") that does not look for the particular file name
> that is about to be written, but seems to try and list the whole
> current directory's content with a pattern of "*". Note that,
> looping through the 2000 files to be written in my scenario, the
> length of the Samba's Find Response increases with every file
> successfully copied: When copying file number 1000, the Find
> Response sends back a list of all 999 files that have been
> successfully copied to this directory before, and this list of 999
> file names is not needed for any meaningful purpose, as the goal
> only is to check whether file number 1000 already exists in this
> list of 999 files (which it of course never
> does!) or not. The last such call to
> SMB2_FIND_ID_BOTH_DIRECTORY_INFO contained in the traces has a
> response length of about 64kB (containing filenames that have
> already been written to the target directory but are not
> needed/helpful in any way) and interestingly does not return
> "STATUS_NO_MORE_FILES", but "STATUS_INFO_LENGTH_MISMATCH", maybe
> because the buffer size for the result of the pattern lookup is only
> 64kB!?

This might be hidden against Windows due to directory
handle leases, which we don't yet support.