[cifs-protocol] STATUS_OS2_INVALID_LEVEL

Bill Wesse billwe at microsoft.com
Thu Jan 14 06:44:42 MST 2010

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).

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

I have no doubt a complete rundown of all the exceptions to the rule would be quite valuable to our respective organizations and customers - 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.

There I go again. Another understatement.

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: Wednesday, January 13, 2010 5:17 PM
To: tim.prouty at isilon.com; Jeremy Allison; pfif at tridgell.net; cifs-protocol at samba.org
Cc: Gary Shang; Bill Wesse; José Rivera

Tim, et. al.,

I just caught wind of a ticket opened internally at Microsoft HQ that was
generated by a question you asked.  As a result of this ticket, a change was
recommended for [MS-CIFS] that would have caused a good deal of trouble so I
am sending this out in an effort to clarify things a bit.

[MS-CIFS] states this:

	If this bit is set in a client request, the server MUST return
	errors as 32-bit NTSTATUS codes in the response. If it is clear,
	the server MUST return errors in SMBSTATUS format.

That's the way it *should* work.

In fact, there is a whole set of 32-bit status codes that are wire-identical
to the DOS&OS/2 style Class/Code pairs.  For example,
STATUS_OS2_INVALID_LEVEL is defined as 0x007C0001, which is exactly the same
(on the wire) as ERRDOS/ERRunknownlevel (0x01/0x007C).

Gary:  I have had a little more time to look at this and consider the
       implications of the capture Tim provided.  My thoughts:

* Windows 7 SHOULD be returning a 32-bit code.  The code SHOULD be
  STATUS_OS2_INVALID_LEVEL which, as stated above, is identical to
  ERRDOS/ERRunknownlevel.  That is, The value in the Status field
  returned by Windows 7 is correct no matter how you cut it.

* Windows 7 SHOULD NOT be clearing the SMB_FLAGS2_NT_STATUS bit in
  the response.  (Gary:  This is where your proposed change was

  + Note that [MS-CIFS] covers Windows NT only, so we need to see if NT
    changes this bit as well.  If so, then we add a WBN in [MS-CIFS].
    If not, then the WBN belongs in [MS-SMB].

Bill W's comment in the earlier thread, stating that the status code
management in NT is complex, is a polite understatement.  We spent months
trying to figure this out.

In [MS-CIFS], you will find several 32-bit status codes defined that are
wire-identical to old-style Class/Code pairs.


...all of the above are wire identical whether they are viewed as NTSTATUS

Chris -)-----

PS.  I somehow got kicked off of the cifs-protocol list a while back and
can't seem to get re-registered so please make sure I'm in the CC list if
you respond.

"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

More information about the cifs-protocol mailing list