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