Sorry about that - I don't actually have the test machines (I couldn't
find a WindowsCE machine to test with) and the user didn't say what
the test program was - but I think it was the "dir" command.   I will
ask him.

On Tue, Aug 30, 2011 at 3:04 PM, Hongwei Sun <[email protected]> wrote:
> Steve,
>
>  Any update ?
>
> Thanks!
>
> Hongwei
>
>
> -----Original Message-----
> From: Hongwei Sun
> Sent: Thursday, August 25, 2011 4:26 PM
> To: 'Steve French'
> Cc: Edgar Olougouna; [email protected]; [email protected]; MSSolve Case 
> Email
> Subject: RE: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst 
> rejected by some Windows servers even though NTLM
>
> Steve,
>
>  What program or API are you using on Windows client to test FIND_FIRST2 
> command ?    Have you observed that the same Windows client sends the 
> different information level while connecting to different server ?    The 
> client (redirector) maps the application-provided [MS-FSCC] information 
> levels to a SMB information Level.    SMB_FIND_FILE_BOTH_DIRECTORY_INFO is 
> mapped to FileBothDirectoryInformation  passed from the application.   I just 
> want to check to see how this is passed from the application.
>
> Thanks!
>
> Hongwei
>
>
> -----Original Message-----
> From: Steve French [mailto:[email protected]]
> Sent: Wednesday, August 24, 2011 4:23 PM
> To: Hongwei Sun
> Cc: Edgar Olougouna; [email protected]; [email protected]; MSSolve Case 
> Email
> Subject: Re: [REG:111081664438980] RE: [cifs-protocol] Level 257 FindFirst 
> rejected by some Windows servers even though NTLM
>
> On Tue, Aug 23, 2011 at 10:43 PM, Hongwei Sun <[email protected]> wrote:
>> Steve,
>>
>>   Windows CE is not within the scope of protocol documentation, such as  
>> MS-SMB and MS-CIFS.   Therefore it is understandable that it doesn't behave 
>> as specified in the protocol documents.
>
> This is more about what Windows clients do not about the WindowsCE server.
>
> Clearly windows clients works (to WindowsCE server) - and it appears it is 
> because they choose levels carefully to avoid the WindowsCE server problems
>
> instead of
> FIND_FILE_DIRECTORY_INFO (level 257)
> nor
> FIND_FILE_FULL_DIRECTORY_INFO (258)
> nor
> FIND_FILE_ID_FULL_DIRECTORY_INFO (262)
>
> Windows clients (XP, Vista, etc) know enough to send 
> SMB_FIND_FILE_BOTH_DIRECTORY_INFO (260)
>
> which doesn't make sense since FIND_FILE_BOTH_DIRECTORY_INFO requires the 
> server to return the short name (which no longer seems relevant to windows 
> clients but they are requesting it - even of WindowsCE).
>
> Windows is NOT returning operation not supported (or the eqiuvalent) to the 
> application, rather it is selectively choosing to use level 260 (rather than 
> the 3 other more logical find levels)
>
> So the question is - how does Windows (clients) determine which level to 
> request on FindFirst - in particular when not to use 257, 258 or
> 262 and fall back to 260?
>
>>   As far as Windows systems, as per 2.2.2.3.1 MS-CIFS, for Windows NT
>> and earlier, the Find information levels supported are clearly
>> specified
>>
>>   SMB_INFO_STANDARD                                     0x0001
>> (LANMAN2.0)
>>   SMB_INFO_QUERY_EA_SIZE                           0x0002
>> (LANMAN2.0)
>>   SMB_INFO_QUERY_EAS_FROM_LIST          0x0003   (LANMAN2.0)
>>   SMB_FIND_FILE_DIRECTORY_INFO               0x0101   (NT LANMAN)
>>   SMB_FIND_FILE_FULL_DIRECTORY_INFO   0x0102   (NT LANMAN)
>>   SMB_FIND_FILE_NAMES_INFO                       0x0103   (NT LANMAN)
>>   SMB_FIND_FILE_BOTH_DIRECTORY_INFO   0x0104   (NT LANMAN)
>>
>>  For Windows 2000 and later ,  in addition to the levels above , the
>> following levels are added as per MS-SMB 2.2.6.1.1
>>
>>  SMB_FIND_FILE_ID_FULL_DIRECTORY_INFO    0x0105 (NT LANMAN)
>>  SMB_FIND_FILE_ID_BOTH_DIRECTORY_INFO  0x0106  (NT LANMAN)
>>
>>  As per 2.2.8 MS-CIFS,  The client MUST map the application-provided 
>> [MS-FSCC] information levels to SMB information Levels.   For all other 
>> [MS-FSCC] information levels, the client MUST fail the request with 
>> STATUS_NOT_SUPPORTED.   In some case, the client MUST send a fixed level.   
>> For example, a client that has not negotiated long names support MUST 
>> request only  SMB_INFO_STANDARD.
>>
>>  Please let us know if you have more questions.
>>
>> Thanks!
>>
>> Hongwei
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Steve French
>> Sent: Thursday, August 18, 2011 4:54 PM
>> To: Edgar Olougouna
>> Cc: [email protected]; [email protected]
>> Subject: Re: [cifs-protocol] Level 257 FindFirst rejected by some
>> Windows servers even though NTLM
>>
>> It looks like Windows CE takes (only?) level 260 but I can't easily prove it 
>> without access to a test system (I just have some customer traces) - so how 
>> does Windows clients (Windows XP/Vista/7 etc.) determine which FindFirst 
>> level to send to these given that the Microsoft server in this case is 
>> reporting NT Find and NT SMB support but in practice not supporting most 
>> FindFirst levels.
>>
>> On Tue, Aug 16, 2011 at 12:56 PM, Edgar Olougouna <[email protected]> 
>> 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:[email protected]]
>>> Sent: Tuesday, August 16, 2011 12:35 PM
>>> To: Interoperability Documentation Help
>>> Cc: [email protected]; [email protected]
>>> 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
>> _______________________________________________
>> cifs-protocol mailing list
>> [email protected]
>> https://lists.samba.org/mailman/listinfo/cifs-protocol
>>
>>
>
>
>
> --
> Thanks,
>
> Steve
>
>



-- 
Thanks,

Steve
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to