16.3 Readin , Writin , and Rithmatic

16.3 Readin', Writin', and 'Rithmatic

Here is a quick run-down on some of the basic essentials of SMB.

OPEN_ANDX

This SMB is discussed in examples given throughout the SNIA doc, but there is no actual writeup given there. That's because it was labeled as "obsolescent" in the Leach/Naik CIFS draft. The NT_CREATE_ANDX SMB is now considered the more fashionable choice. Servers must still support the OPEN_ANDX SMB, however, and there are certainly clients that still send it (even under the NT LM 0.12 dialect ).

It's times like these that the earlier documentation comes in really handy.

The OPEN_ANDX SMB is used to gain access to a file for further processing (reading, writing, that sort of thing). The open file is identified by a FID ( F ile ID ). The FID , of course, is returned by a successful OPEN_ANDX call.

READ_ANDX

It seems fairly obvious. This one lets you read blocks of data from a file (or device) on the server. The READ_ANDX request supports 64-bit file offsets if the OffsetHigh field is present (if it is present, the WordCount will be 12).

An oddity of the READ_ANDX is the MaxCountHigh field, which is only used if the CAP_LARGE_READX capability has been set. MaxCountHigh is an unsigned long (four bytes) that is supposed to hold the upper 16 bits (two bytes) of the unsigned short (two byte) MaxCount field. Two problems with this:

  1. Why use a 32-bit field to hold 16 bits worth of data?

  2. Even with CAP_LARGE_READX set, the maximum SMB large read is 64K. That should fit into the MaxCount field with no need for MaxCountHigh .

    Play with it and see what happens. Should be interesting.

WRITE_ANDX

Allows writing to a file or device. This SMB can also be extended by two words to include an OffsetHigh field, thus providing 64-bit offsets. There is also a DataLengthHigh field that is comparable to the MaxCountHigh from the READ_ANDX . In this case, though, the DataLengthHigh field is given as an unsigned short. That's only two bytes, which makes more sense.

SEEK_ANDX

This one may be considered deprecated. Newer clients probably don't need to send the SEEK_ANDX , but servers may need to support it just in case.

Email

graphics/email.gif


From:  Charles  Caldarale
   To:  jCIFS  Mailing  List

SMB_COM_SEEK  is  a  useless  SMB,  since  all  of  the  read  and  write
functions  require  a  file  relative  address.  It's  not  surprising
it  wasn't  used;  it  would  have  been  a  waste  of  network  bandwidth
if  it  had  been  sent.

-  Chuck

See also the SNIA doc's comments regarding this SMB.

FLUSH

The SMB_COM_FLUSH has nothing to do with plumbing. It is sent by the client to ask the server to write all data and metadata for an open file (specified by its FID ) to disk. If a FID value of 0xFFFF is given, the server is being asked to flush all open files relative to the TID .

NT_CREATE_ANDX

This SMB is used to open, create, or overwrite a file or directory. It offers a myriad of options for file attributes, file sharing, security, etc. As the "NT" in the name implies, the NT_CREATE_ANDX SMB is closely tied to the feature set offered by Windows NT filesystem calls. Here's where you start needing to know more about Windows itself.

One problem with complex calls such as this is that the number of permutations gets to be very high, and it quickly becomes very difficult to test them all. [1] There are various reports describing combinations of values that can cause a Windows NT client or server to go BSOD ( B lue S creen O f D eath). Have fun with your testing.

[1] I vaguely remember a presentation given by David Korn, author of the Korn Shell (ksh), regarding AT&T's UWIN project. At the end of the presentation there was some discussion regarding the differences between standard Posix APIs and Win32 APIs. It was pointed out that there were hundreds or possibly thousands of permutations of parameter values that could be passed to the Posix open() function. The permutations for the equivalent Win32 function, it was reported , was on the order of millions. How the heck do you test all those possibilities?

There is yet another version of this SMB known as the NT_TRANSACT_CREATE , which is implemented as a sub-command of the SMB_COM_NT_TRANSACTION SMB. It is used to apply Extended Attributes (EAs) or Security Descriptors (SDs) to a file or directory.

CLOSE

All good things must come to an end. Close the file, say goodnight, sing one more song, and get some rest.

Remember earlier when we talked about SMB messages as if we were dissecting some strange , new species of multi-legged critter? Well, we've moved beyond Entomology, Invertebrate Zoology, Taxonomy, and such. We're now studying really complex stuff like Sociology, Psychology, and Numismatics, and we get to put the little critters into Skinner boxes and see how they react to various stimuli. It's important research, and there are all sorts of interesting things to discover.

Consider, for example, the SMB_COM_COPY command. It's supposed to allow you to copy a file from one location on the server to another location. That saves the client from having to read the data over the wire and write it back again. A good idea, eh? Unfortunately, no one seems to be able to get it to work at least, not against Windows servers. There has been some limited success in the laboratory...

Email

graphics/email.gif

 From: Greg McCain      To: Chris Hertel Subject: CIFS and SMB_COPY Chris, I found that smb_copy will in fact copy a file iff:  - the src file is in the root of the share  - you do not specify the full path to the file src and dest files in the smb_copy command. Instead, just specify the names of the files (this is out of spec.). The resulting destination file will be named like the source file, minus the first character. It will NOT be named as specified in the dest parameter. Hence "smb_copy wanda -> fred" results in a second file "anda" in the root of the share. This works on the .NET server RC1 and Windows 2000 servers that I've tried. Hope it helps. 

SMB is an old protocol, and it has gotten sloppy over the years . As you work your way through the SMB messages, implementing first the easy ones and then the more difficult ones, keep this thought in mind: It's not your fault.

Say it to yourself now: "It's not my fault."

Very good.

That will prevent you from getting frustrated and doubting your own skill. It's really not your fault.



Implementing CIFS. The Common Internet File System
Implementing CIFS: The Common Internet File System
ISBN: 013047116X
EAN: 2147483647
Year: 2002
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net