From Bruce_Leverett@TRANSARC.COM Tue Jan 20 19:22:29 1998 Date: Tue, 20 Jan 1998 13:29:39 -0500 From: Bruce_Leverett@TRANSARC.COM Reply-To: Common Internet File System To: CIFS@DISCUSS.MICROSOFT.COM Subject: Re: new CIFS I-D Status, Abstract, Table of Contents It makes my life harder, not easier, that obsolescent requests are in a separate document. This has even been extended to the definitions of flags in 3.2.2 and 3.2.3. If I could file the "Obsolescent Messages" manual in some dusty archive, it would be great, but instead it has to be right up there on the shelf with the latest CIFS spec, because the clients I work with send me lots of obsolescent messages. Hmm. I suppose that from your point of view, splitting the "Obsolescent Messages" to a separate manual has the advantage that that manual shouldn't have to be updated quite as frequently. If that's the rationale, then I can sympathize. It is unfortunate that the table of contents has only two levels. There is no way to look up a particular message, other than linear search. What a nightmare. 3.2.1 SMB Header A word about alignment. If I define a structure like this: struct A { char B; short C; char D; }; Many C compilers will align C on a short boundary. The result is that there is an unused byte between B and C, and the A structure is 5 bytes long. The definition of SMB_HEADER does not assume this alignment. I had to figure this out by reading other people's code and by sniffing. It would be helpful if this (non-)assumption were explicitly stated. 3.2.2 and others Apparently, the convention used is that bits are numbered starting at 0, with 0 being lowest-order. This convention should be explicitly stated. Again, I had to figure this out by reading code and sniffing. 3.2.2 and 3.2.3 It is good that these flags now have names. I see that the names do not match the names printed by smbtrace (from the Windows NT Resource Kit). I suppose it would be more surprising if they did, than it is that they do not. Too bad. 3.4 Wildcards "If the negotiated dialect is 'NT LM 0.12' or later, and the client requires MS-DOS wildcard matching semantics ..." I have not figured out what exactly this means. What alternative matching semantics are there? How are MS-DOS semantics different from others? In my server, am I to treat "?" differently from ">"? Or are they equivalent? Likewise for "." and """", and for "*" and "<". 3.6 Time and Date Encoding This section is actually OK, it's the later sections I am complaining about. For instance, in 4.2.13.8 (picked at random), some time/date fields are specified as having type LARGE_INTEGER. I presume the intent was TIME. All time/date fields in the document should have types taken from this section (3.6). 3.8 Access Mask Encoding This section does not adequately specify the flags used by the NT_CREATE_ANDX message. I do not have the details handy, but I can find them if it would be helpful. 3.15 Valid SMB Requests by Negotiated Dialect This section lists SMB_COM_NT_RENAME, but no such request is listed in Section 5.1, "SMB Command Codes." By sniffing and trial-and-error, I have found that information levels in some SMB requests (such as TRANS2_FIND_FIRST2, TRANS2_QUERY_PATH_INFORMATION, etc.) depend on negotiated dialect. A listing of these is necessary and would be a logical candidate for this section. 4.1.1 Negotiate A one sentence explanation of the semantics of CAP_NT_FIND is necessary. What's the idea, is this Microsoft Confidential? :-) It is claimed that CAP_RAW_MODE is obsolescent. What does this mean? Some time ago, I had a version of my server that negotiated NT LM 0.12 but left CAP_RAW_MODE clear, thinking that I could thereby use NT status codes without having to implement raw mode. But the NT client sent me raw mode messages anyhow. I wrote off to the CIFS Spec gurus (you and two others) and you were quite surprised. Any connection between this and the statement that CAP_RAW_MODE is obsolescent? 4.1.2.2 (Session Setup And X) NT LM 0.12 STATUS_MORE_PROCESSING_REQUIRED is misspelled. Here again a description of CAP_NT_FIND would be appropriate. However, I have to say that the CAP_NT_SMBS and CAP_NT_FIND bits in the client Session Setup message are ignored by my server (and by others, I presume). 4.1.4 Tree Connect And X What does SMB_SUPPORT_SEARCH_BITS do? I found that the Win 95 client pays attention to the Native File System in the response to Tree Connect And X in a most surprising way. In the earlier response to Negotiate, I had specified CAP_NT_FIND, but the Win 95 client ignored this unless I also (subsequently) specified something like "NTFS" or "FAT" in the response to Tree Connect And X. (I had originally specified "AFS".) I suppose that a description of this eccentric client behavior might not be appropriate in your CIFS spec. But perhaps some kind of warning is in order, possibly in section 4.1.2, indicating that clients may ignore some capabilities for more or less arbitrary reasons. Also, stating that the CIFS spec may not be an "appropriate" place for this information does not address my basic problem as a server implementor, which is to find out how clients behave, without trial-and-error and sniffing. Does Microsoft publish specs for their SMB client and server? If so, where can I find them? If not, why not? 4.1.6.6 (TRANS2_QUERY_FS_INFORMATION) SMB_QUERY_FS_ATTRIBUTE_INFO FILE_PERSISTENT_ACLS is misspelled. (Or is it?) What is the meaning of FILE_PERSISTENT_ACLS? Can you point me to a relevant Microsoft document? Sniffing at Samba, I observed that it was setting bit 0x4000 in the File System Attributes. Does this bit mean anything? 4.2.1 NT Create And X I mentioned earlier that the description of ACCESS_MASK (3.8) is incomplete, enough so as to be useless. The description of CreateDisposition is completely wrong. (Or should I say, completely at variance with the NT client and server; I am assuming this means that the spec is wrong, not the client and server.) I can provide details if it would be helpful. I found a usable description in the documentation of NtCreateFile in the DDK. The Name is apparently (in the NT client) not null-terminated. I don't know if this is a bug or an intended spec. 4.2.10 Rename File I don't understand this: "Multiple files may be renamed ... as Rename File supports wildcards in the file name". Can you give an example? 4.2.13.4 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_BASIC_INFO From sniffing the NT client and server, I observed that instead of a USHORT attributes, the data ended with two longs, of which the first was apparently extended attributes, and the second was unknown (always zero). I have not yet checked this out with the Windows 95 client. I found that my server had to conform to the above description, rather than to the CIFS spec, to please the NT client. 4.2.13.7 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_NAME_INFO Is the whole file name to be used, or just the last component? 4.2.13.9 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_ALT_NAME_INFO A sentence describing this is necessary. I figured out by sniffing that this was for getting the 8.3 name, given the long name. 4.2.13.10 (TRANS2_QUERY_PATH_INFORMATION) SMB_QUERY_FILE_STREAM_INFO What is an appropriate response to this, if the server does not support streams? I used sniffing to figure something out here. 4.2.16 TRANS2_SET_FILE_INFORMATION There is no description for SMB_FILE_BASIC_INFO. A whole subsection is missing! 4.3.3 Check Directory What if the path turns out to specify a file (non-directory)? My server returns ERRDOS/ERRbadpath, or STATUS_OBJECT_PATH_INVALID. 4.3.4 TRANS2_FIND_FIRST2 If this search finds no names, should it return an error code? My server does not, and this has worked OK so far on NT, but I noticed that the NT server returned STATUS_NO_SUCH_FILE when responding to the Win 95 client. Resume keys are not used for information levels above (and including) 0x101. I found that there were some alignment requirements when responding to the NT client. I ended up doing the following: - The parameter block for the response to SMB_COM_TRANSACTION2 is aligned on a short boundary. - The data block for the response to SMB_COM_TRANSACTION2 is aligned on a longword boundary. - For the response to TRANS2_FIND_FIRST2, each individual entry is aligned on a longword boundary. Some of these would not have been necessary. 4.3.7 NT_TRANSACT_NOTIFY_CHANGE A flow diagram is necessary here. I didn't know what would happen if I just ignored this message. I sniffed and found that there would eventually be a NT_CANCEL to which, if I didn't have anything useful to say, I was supposed to reply with STATUS_CANCELED. Also, I didn't know if I could just reject this message (e.g. STATUS_NOT_IMPLEMENTED). 5.4 SMB Protocol Dialect Constants I haven't figured out the difference between LM1.2X002 and DOS LM1.2X002. The Win95 client offers the latter, the NT client offers the former. My server handled both without modification. So how are they different? The text says, "... the server will perform error mapping to appropriate DOS errors." What does this mean? When my server negotiates LM1.2X002 or DOS LM1.2X002, it uses the error codes in Chapter 6. Am I supposed to be doing something different? 6 Error Codes and Classes Why isn't ERRHRD/39 in here? (I was told to use it for "disk full", and I do.) This section was (nearly) useless when I went over to NT status codes. I had to determine what NT status codes to use by (what else?) sniffing. Some listing of appropriate codes is necessary. ---------------------------------------------------------------- Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://discuss.microsoft.com/archives/index.html