[cifs-protocol] STATUS_OS2_INVALID_LEVEL

[Bill Wesse]

Thanks for the clarification about the SMB_FLAGS2_NT_STATUS bit flipping (I inadvertently generalized that to your comments concerning 32-bit wire-identical to DOS&OS/2 style Class/Code pairs).

As you have already seen (or will no doubt shortly see), the internal conversation about whose lap the work will land in is expanding.

Concerning the supplemental content (if that becomes necessary), a KB sounds reasonable - we do have some KBs that fall into that brain space (for example, the following, which I think may need an update):

INFO: Mapping NT Status Error Codes to Win32 Error Codes
http://support.microsoft.com/kb/113996

On that same topic, I am sure there are better formats that could made available on a possible Blog entry (http://blogs.msdn.com/OpenSpecification); zipped attachments there could include .csv (or tab-delimited) files running this down (and don't we all love those when we have source identifiers / enum's / data to declare...). Nothing like a good old-fashioned regex party!

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
Email:	billwe at microsoft.com
Tel: 	+1(980) 776-8200
Cell: 	+1(704) 661-5438
Fax: 	+1(704) 665-9606

-----Original Message-----
From: Christopher R. Hertel [mailto:crh at ubiqx.mn.org] 
Sent: Thursday, January 14, 2010 2:16 PM
To: Bill Wesse
Cc: tim.prouty at isilon.com; Jeremy Allison; pfif at tridgell.net; cifs-protocol at samba.org; Gary Shang; José Rivera
Subject: Re: STATUS_OS2_INVALID_LEVEL

Bill Wesse wrote:
> Thanks for the heads up Christopher - you are totally correct in saying
> my comments on the complexity of NT platform SMB error returns were
> meant to be 'polite understatements' (especially that pesky flipped
> response SMB_FLAGS2_NT_STATUS bit, not to mention the 'occasionally
> optional' WordCount and ByteCount absence from transact2 responses).

The thing about the flipped bit:  The SMB_FLAGS2_NT_STATUS bit is *NOT*
cleared by Windows NT when sending one of the suspect error codes.  NT, that
is, is saying that it's a 32-bit code.  We've documented these codes as such
in [MS-CIFS].  It makes it MUCH easier to document the entire problem.

Basically, though, what we're dealing with is a 20-year-old kludge with no
clear fix.  It simply needs to be explained so that implementers can work
with it.

> I will shortly forward your email to concerned internal parties...

I'm available internally as v-chhert.
Yeah... I'm a double agent!  :)
Say hello to Will and Darryl for me.

> I have no doubt a complete rundown of all the exceptions to the rule
> would be quite valuable to our respective organizations and customers

It's difficult to get the documentation right but it can be explained and
doing so would probably help you guys out.

> - figuring what to do in response to a 'surprise' error value classifies
> as yet another 'polite understatement'.

:)

> 
> I won't rule out the possibility of (my team) providing supplemental
> content concerning this, in case the documents aren't the optimal place
> for the info - I hate to state the obvious, but a complete WB
> description of the above for all NT/SMB (or just transact2) would be
> pretty big.

Perhaps a KB article that we can reference from a WB?

> 
> There I go again. Another understatement.

:)

Chris -)-----


> --
> "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
> Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
> jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
> ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
> OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org
> 
>