[cifs-protocol] Level 257 FindFirst rejected by some Windows servers even though NTLM

[Steve French]

Loosely related question - how do the normal windows desktops clients
determine how to fall back (or move up to newer) infolevels for
FindFirst.   We would normally use SMB_FIND_FILE_ID_FULL_DIR_INFO
(level 0x105 FindFirst) but we end up calling FindFirst level 0x101
(which does not request "uniqueids") since QueryPathInfo level 0x3EE
(QueryFileInternalInfo) gets NT Status: STATUS_INVALID_LEVEL
(0xc0000148) fails.

On Tue, Aug 16, 2011 at 12:56 PM, Edgar Olougouna <edgaro at microsoft.com> wrote:
> [Dochelp to bcc]
>
> Steve,
>
> One of our engineers will follow-up soon on this inquiry. The case number is 111081664438980.
>
> Regards,
> Edgar
>
> -----Original Message-----
> From: Steve French [mailto:smfrench at gmail.com]
> Sent: Tuesday, August 16, 2011 12:35 PM
> To: Interoperability Documentation Help
> Cc: cifs-protocol at samba.org; pfif at tridgell.net
> Subject: Level 257 FindFirst rejected by some Windows servers even though NTLM
>
> A user sent me a trace of FindFirst level 257 (0x101 ) failing to Windows CE with NT Status: STATUS_INVALID_LEVEL (0xc0000148)
>
> even though dialect negotiated was NT LM 012 and that dialect is the only prereq listed in MS-SMB for the level (see page 64).
>
> How can the client determine under what condition that the server does not support that level - -  and what level to fall back (or move up to
> higher level)?   Level 257 is pretty basic.
>
>
> --
> Thanks,
>
> Steve
>
>



-- 
Thanks,

Steve