1 THIS IS INCOMPLETE! I'M ONLY COMMITING IT IN ORDER TO SOLICIT COMMENTS
2 FROM A FEW PEOPLE. DON'T TAKE THIS AS THE FINAL VERSION YET.
5 Samba4 Programming Guide
6 ------------------------
8 The internals of Samba4 are quite different from previous versions of
9 Samba, so even if you are an experienced Samba developer please take
10 the time to read through this document.
12 This document will explain both the broad structure of Samba4, and
13 some of the common coding elements such as memory management and
20 In past versions of Samba we have basically let each programmer choose
21 their own programming style. Unfortunately the result has often been
22 that code that other members of the team find difficult to read. For
23 Samba version 4 I would like to standardise on a common coding style
24 to make the whole tree more readable. For those of you who are
25 horrified at the idea of having to learn a new style, I can assure you
26 that it isn't as painful as you might think. I was forced to adopt a
27 new style when I started working on the Linux kernel, and after some
28 initial pain found it quite easy.
30 That said, I don't want to invent a new style, instead I would like to
31 adopt the style used by the Linux kernel. It is a widely used style
32 with plenty of support tools available. See Documentation/CodingStyle
33 in the Linux source tree. This is the style that I have used to write
34 all of the core infrastructure for Samba4 and I think that we should
35 continue with that style.
37 I also think that we should most definately *not* adopt an automatic
38 reformatting system in cvs (or whatever other source code system we
39 end up using in the future). Such automatic formatters are, in my
40 experience, incredibly error prone and don't understand the necessary
41 exceptions. I don't mind if people use automated tools to reformat
42 their own code before they commit it, but please do not run such
43 automated tools on large slabs of existing code without being willing
44 to spend a *lot* of time hand checking the results.
46 Finally, I think that for code that is parsing or formatting protocol
47 packets the code layout should strongly reflect the packet
48 format. That means ordring the code so that it parses in the same
49 order as the packet is stored on the wire (where possible) and using
50 white space to align packet offsets so that a reader can immediately
51 map any line of the code to the corresponding place in the packet.
54 Static and Global Data
55 ----------------------
57 The basic rule is "avoid static and global data like the plague". What
58 do I mean by static data? The way to tell if you have static data in a
59 file is to use the "size" utility in Linux. For example if we run:
63 in Samba4 then you get the following:
65 text data bss dec hex filename
66 2015 0 0 2015 7df libcli/raw/clikrb5.o
67 202 0 0 202 ca libcli/raw/clioplock.o
68 35 0 0 35 23 libcli/raw/clirewrite.o
69 3891 0 0 3891 f33 libcli/raw/clisession.o
70 869 0 0 869 365 libcli/raw/clisocket.o
71 4962 0 0 4962 1362 libcli/raw/clispnego.o
72 1223 0 0 1223 4c7 libcli/raw/clitransport.o
73 2294 0 0 2294 8f6 libcli/raw/clitree.o
74 1081 0 0 1081 439 libcli/raw/raweas.o
75 6765 0 0 6765 1a6d libcli/raw/rawfile.o
76 6824 0 0 6824 1aa8 libcli/raw/rawfileinfo.o
77 2944 0 0 2944 b80 libcli/raw/rawfsinfo.o
78 541 0 0 541 21d libcli/raw/rawioctl.o
79 1728 0 0 1728 6c0 libcli/raw/rawnegotiate.o
80 723 0 0 723 2d3 libcli/raw/rawnotify.o
81 3779 0 0 3779 ec3 libcli/raw/rawreadwrite.o
82 6597 0 0 6597 19c5 libcli/raw/rawrequest.o
83 5580 0 0 5580 15cc libcli/raw/rawsearch.o
84 3034 0 0 3034 bda libcli/raw/rawsetfileinfo.o
85 5187 0 0 5187 1443 libcli/raw/rawtrans.o
86 2033 0 0 2033 7f1 libcli/raw/smb_signing.o
88 notice that the "data" and "bss" columns are all zero? That is
89 good. If there are any non-zero values in data or bss then that
90 indicates static data and is bad (as a rule of thumb).
92 Lets compare that result to the equivalent in Samba3:
94 text data bss dec hex filename
95 3978 0 0 3978 f8a libsmb/asn1.o
96 18963 0 288 19251 4b33 libsmb/cliconnect.o
97 2815 0 1024 3839 eff libsmb/clidgram.o
98 4038 0 0 4038 fc6 libsmb/clientgen.o
99 3337 664 256 4257 10a1 libsmb/clierror.o
100 10043 0 0 10043 273b libsmb/clifile.o
101 332 0 0 332 14c libsmb/clifsinfo.o
102 166 0 0 166 a6 libsmb/clikrb5.o
103 5212 0 0 5212 145c libsmb/clilist.o
104 1367 0 0 1367 557 libsmb/climessage.o
105 259 0 0 259 103 libsmb/clioplock.o
106 1584 0 0 1584 630 libsmb/cliprint.o
107 7565 0 256 7821 1e8d libsmb/cliquota.o
108 7694 0 0 7694 1e0e libsmb/clirap.o
109 27440 0 0 27440 6b30 libsmb/clirap2.o
110 2905 0 0 2905 b59 libsmb/clireadwrite.o
111 1698 0 0 1698 6a2 libsmb/clisecdesc.o
112 5517 0 0 5517 158d libsmb/clispnego.o
113 485 0 0 485 1e5 libsmb/clistr.o
114 8449 0 0 8449 2101 libsmb/clitrans.o
115 2053 0 4 2057 809 libsmb/conncache.o
116 3041 0 256 3297 ce1 libsmb/credentials.o
117 1261 0 1024 2285 8ed libsmb/doserr.o
118 14560 0 0 14560 38e0 libsmb/errormap.o
119 3645 0 0 3645 e3d libsmb/namecache.o
120 16815 0 8 16823 41b7 libsmb/namequery.o
121 1626 0 0 1626 65a libsmb/namequery_dc.o
122 14301 0 1076 15377 3c11 libsmb/nmblib.o
123 24516 0 2048 26564 67c4 libsmb/nterr.o
124 8661 0 8 8669 21dd libsmb/ntlmssp.o
125 3188 0 0 3188 c74 libsmb/ntlmssp_parse.o
126 4945 0 0 4945 1351 libsmb/ntlmssp_sign.o
127 1303 0 0 1303 517 libsmb/passchange.o
128 1221 0 0 1221 4c5 libsmb/pwd_cache.o
129 2475 0 4 2479 9af libsmb/samlogon_cache.o
130 10768 32 0 10800 2a30 libsmb/smb_signing.o
131 4524 0 16 4540 11bc libsmb/smbdes.o
132 5708 0 0 5708 164c libsmb/smbencrypt.o
133 7049 0 3072 10121 2789 libsmb/smberr.o
134 2995 0 0 2995 bb3 libsmb/spnego.o
135 3186 0 0 3186 c72 libsmb/trustdom_cache.o
136 1742 0 0 1742 6ce libsmb/trusts_util.o
137 918 0 28 946 3b2 libsmb/unexpected.o
139 notice all of the non-zero data and bss elements? Every bit of that
140 data is a bug waiting to happen.
142 Static data is evil as it has the following consequences:
143 - it makes code much less likely to be thread-safe
144 - it makes code much less likely to be recursion-safe
145 - it leads to subtle side effects when the same code is called from
148 Static data is particularly evil in library code (such as our internal
149 smb and rpc libraries). If you can get rid of all static data in
150 libraries then you can make some fairly strong guarantees about the
151 behaviour of functions in that library, which really helps.
153 Of course, it is possible to write code that uses static data and is
154 safe, it's just much harder to do that than just avoid static data in
155 the first place. We have been tripped up countless times by subtle
156 bugs in Samba due to the use of static data, so I think it is time to
157 start avoiding it in new code. Much of the core infrastructure of
158 Samba4 was specifically written to avoid static data, so I'm going to
159 be really annoyed if everyone starts adding lots of static data back
162 So, how do we avoid static data? The basic method is to use context
163 pointers. When reading the Samba4 code you will notice that just about
164 every function takes a pointer to a context structure as its first
165 argument. Any data that the function needs that isn't an explicit
166 argument to the function can be found by traversing that context.
168 Note that this includes all of the little caches that we have lying
169 all over the code in Samba3. I'm referring to the ones that generally
170 have a "static int initialised" and then some static string or integer
171 that remembers the last return value of the function. Get rid of them!
172 If you are *REALLY* absolutely completely certain that your personal
173 favourite mini-cache is needed then you should do it properly by
174 putting it into the appropriate context rather than doing it the lazy
175 way by putting it inside the target function. I would suggest however
176 that the vast majority of those little caches are useless - don't
177 stick it in unless you have really firm benchmarking results that show
178 that it is needed and helps by a significant amount.
180 Note that Samba4 is not yet completely clean of static data like
181 this. I've gotten the smbd/ directory down to 24 bytes of static data,
182 and libcli/raw/ down to zero. I've also gotten the ntvfs layer and all
183 backends down to just 8 bytes in ntvfs_base.c. The rest still needs
186 Also note that truly constant data is OK, and will not in fact show up
187 in the data and bss columns in "size" anyway (it will be included in
188 "text"). So you can have constant tables of protocol data.
194 We introduced the talloc() system for memory contexts during the 2.2
195 development cycle and it has been a great success. It has greatly
196 simplified a lot of our code, particularly with regard to error
199 In Samba4 we use talloc even more extensively to give us much finer
200 grained memory management. The really important thing to remember
201 about talloc in Samba4 is:
203 "don't just use the first talloc context that comes to hand - use
204 the RIGHT talloc context"
206 Just using the first talloc context that comes to hand is probably the
207 most common systematic bug I have seen so far from programmers that
208 have worked on the Samba4 code base. The reason this is vital is that
209 different talloc contexts have vastly different lifetimes, so if you
210 use a talloc context that has a long lifetime (such as one associated
211 with a tree connection) for data that is very short lived (such as
212 parsing an individual packet) then you have just introduced a huge
215 In fact, it is quite common that the correct thing to do is to create
216 a new talloc context for some little function and then destroy it when
217 you are done. That will give you a memory context that has exactly the
220 You should also go and look at a new talloc function in Samba4 called
221 talloc_steal(). By using talloc_steal() you can move a lump of memory
222 from one memory context to another without copying the data. This
223 should be used when a backend function (such as a packet parser)
224 produces a result as a lump of talloc memory and you need to keep it
225 around for a longer lifetime than the talloc context it is in. You
226 just "steal" the memory from the short-lived context, putting it into
227 your long lived context.
233 One of the biggest changes in Samba4 is the universal use of interface
234 structures. Go take a look through include/smb_interfaces.h now to get
235 an idea of what I am talking about.
237 In Samba3 many of the core wire structures in the SMB protocol were
238 never explicitly defined in Samba. Instead, our parse and generation
239 functions just worked directly with wire buffers. The biggest problem
240 with this is that is tied our parse code with out "business logic"
241 much too closely, which meant the code got extremely confusing to
244 In Samba4 we have explicitly defined interface structures for
245 everything in the protocol. When we receive a buffer we always parse
246 it completely into one of these structures, then we pass a pointer to
247 that structure to a backend handler. What we must *not* do is make any
248 decisions about the data inside the parse functions. That is critical
249 as different backends will need different portions of the data. This
250 leads to a golden rule for Samba4:
252 "don't design interfaces that lose information"
254 In Samba3 our backends often received "condensed" versions of the
255 information sent from clients, but this inevitably meant that some
256 backends could not get at the data they needed to do what they wanted,
257 so from now on we should expose the backends to all of the available
258 information and let them choose which bits they want.
260 Ok, so now some of you will be thinking "this sounds just like our
261 msrpc code from Samba3", and while to some extent this is true there
262 are extremely important differences in the approach that are worth
265 In the Samba3 msrpc code we used explicit parse strucrures for all
266 msrpc functions. The problem is that we didn't just put all of the
267 real variables in these structures, we also put in all the artifacts
268 as well. A good example is the security descriptor strucrure that
269 looks like this in Samba3:
271 typedef struct security_descriptor_info
276 uint32 off_owner_sid;
287 The problem with this structure is all the off_* variables. Those are
288 not part of the interface, and do not appear in any real descriptions
289 of Microsoft security descriptors. They are parsing artifacts
290 generated by the IDL compiler that Microsoft use. That doesn't mean
291 they aren't needed on the wire - indeed they are as they tell the
292 parser where to find the following four variables, but they should
293 *NOT* be in the interface structure.
295 In Samba3 there were unwritten rules about which variables in a
296 strucrure a high level caller has to fill in and which ones are filled
297 in by the marshalling code. In Samba4 those rules are gone, because
298 the redundent artifact variables are gone. The high level caller just
299 sets up the real variables and the marshalling code worries about
300 generating the right offsets.
302 The same rule applies to strings. In many places in the SMB and MSRPC
303 protocols complex strings are used on the wire, with complex rules
304 about padding, format, alighment, termination etc. None of that
305 information is useful to a high level calling routine or to a backend
306 - its all just so much wire fluff. So, in Samba4 these strings are
307 just "char *" and are always in our internal multi-byte format (which
308 is usually UTF8). It is up to the parse functions to worry about
309 translating the format and getting the padding right.
311 The one exception to this is the use of the WIRE_STRING type, but that
312 has a very good justification in terms of regression testing. Go and
313 read the comment in smb_interfaces.h about that now.
315 So, here is another rule to code by. When writing an interface
316 structure think carefully about what variables in the structure can be
317 left out as they are redundent. If some length is effectively defined
318 twice on the wire then only put it once in the packet. If a length can
319 be inferred from a null termination then do that and leave the length
320 out of the structure completely. Don't put redundent stuff in
327 Samba4 has an asynchronous design. That affects *lots* of the code,
328 and the implications of the asynchronous design needs to be considered
329 just about everywhere.
331 The first aspect of the async design to look at is the SMB client
332 library. Lets take a look at the following three functions in
333 libcli/raw/rawfile.c:
335 struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
336 NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
337 NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
339 Go and read them now then come back.
341 Ok, first notice there there are 3 separate functions, whereas the
342 equivalent code in Samba3 had just one. Also note that the 3rd
343 function is extremely simple - its just a wrapper around calling the
346 The three separate functions are needed because we need to be able to
347 generate SMB calls asynchronously. The first call, which for smb calls
348 is always called smb_raw_XXXX_send(), constructs and sends a SMB
349 request and returns a "struct cli_request" which acts as a handle for
350 the request. The caller is then free to do lots of other calls if it
351 wants to, then when it is ready it can call the smb_raw_XXX_recv()
352 function to receive the reply.
354 If all you want is a synchronous call then call the 3rd interface, the
355 one called smb_raw_XXXX(). That just calls the first two in order, and
356 blocks waiting for the reply.
358 But what if you want to be called when the reply comes in? Yes, thats
359 possible. You can do things like this:
361 struct cli_request *req;
363 req = smb_raw_XXX_send(tree, params);
365 req->async.fn = my_callback;
366 req->async.private = my_private_data;
368 then in your callback function you can call the smb_raw_XXXX_recv()
369 function to receive the reply. Your callback will receive the "req"
370 pointer, which you can use to retrieve your private data from
373 Then all you need to do is ensure that the main loop in the client
374 library gets called. You can either do that by polling the connection
375 using cli_transport_pending() and cli_request_receive_next() or you
376 can use transport->idle.func to setup an idle function handler to call
377 back to your main code. Either way, you can build a fully async
380 In order to support all of this we have to make sure that when we
381 write a piece of library code (SMB, MSRPC etc) that we build the
382 separate _send() and _recv() functions. It really is worth the effort.
384 Now about async in smbd, a much more complex topic.
386 The SMB protocol is inherently async. Some functions (such as change
387 notify) often don't return for hours, while hundreds of other
388 functions pass through the socket. Take a look at the RAW-MUX test in
389 the Samba4 smbtorture to see some really extreme examples of the sort
390 of async operations that Windows supports. I particularly like the
391 open/open/close sequence where the 2nd open (which conflicts with the
392 first) succeeds because the subsequent close is answered out of order.
394 In Samba3 we handled this stuff very badly. We had awful "pending
395 request" queues that allocated full 128k packet buffers, and even with
396 all that crap we got the semantics wrong. In Samba4 I intend to make
397 sure we get this stuff right.
399 So, how do we do this? We now have an async interface between smbd and
400 the NTVFS backends. Whenever smbd calls into a backend the backend has
401 an option of answer the request in a synchronous fashion if it wants
402 to just like in Samba3, but it also has the option of answering the
403 request asynchronously. The only backend that currently does this is
404 the CIFS backend, but I hope the other backends will soon do this to.
406 To make this work you need to do things like this in the backend:
408 req->control_flags |= REQ_CONTROL_ASYNC;
410 that tells smbd that the backend has elected to reply later rather
411 than replying immediately. The backend must *only* do this if
412 req->async.send_fn is not NULL. If send_fn is NULL then it means that
413 the smbd front end cannot handle this function being replied to in an
416 If the backend does this then it is up to the backend to call
417 req->async.send_fn() when it is ready to reply. It the meantime smbd
418 puts the call on hold and goes back to answering other requests on the
421 Inside smbd you will find that there is code to support this. The most
422 obvious change is that smbd splits each SMB reply function into two
423 parts - just like the client library has a _send() and _recv()
424 function, so smbd has a _send() function and the parse function for
427 As an example go and have a look at reply_getatr_send() and
428 reply_getatr() in smbd/reply.c. Read them? Good.
430 Notice that reply_getatr() sets up the req->async structure to contain
431 the send function. Thats how the backend gets to do an async reply, it
432 calls this function when it is ready. Also notice that reply_getatr()
433 only does the parsing of the request, and does not do the reply
434 generation. That is done by the _send() function.
436 The only missing piece in the Samba4 right now that prevents it being
437 fully async is that it currently does the low level socket calls (read
438 and write on sockets) in a blocking fashion. It does use select() to
439 make it somewhat async, but if a client were to send a partial packet
440 then delay before sending the rest then smbd would be stuck waiting
441 for the second half of the packet.
443 To fix this I plan on making the socket calls async as well, which
444 luckily will not involve any API changes in the core of smbd or the
445 library. It just involves a little bit of extra code in clitransport.c
446 and smbd/request.c. As a side effect I hope that this will also reduce
447 the average number of system calls required to answer a request, so we
448 may see a performance improvement.
454 One of the most noticeable changes in Samba4 is the introduction of
455 the NTVFS layer. This provided the initial motivation for the design
456 of Samba4 and in many ways lies at the heart of the design.
458 In Samba3 the main file serving process (smbd) combined the handling
459 of the SMB protocol with the mapping to POSIX semantics in the same
460 code. If you look in smbd/reply.c in Samba3 you see numerous places
461 where POSIX assumptions are mixed tightly with SMB parsing code. We
462 did have a VFS layer in Samba3, but it was a POSIX-like VFS layer, so
463 no matter how you wrote a plugin you could not bypass the POSIX
464 mapping decisions that had already been made before the VFS layer was
467 In Samba4 things are quite different. All SMB parsing is performed in
468 the smbd front end, then fully parsed requests are passed to the NTVFS
469 backend. That backend makes any semantic mapping decisions and fills
470 in the 'out' portion of the request. The front end is then responsible
471 for putting those results into wire format and sending them to the
474 Lets have a look at one of those request structures. Go and read the
475 definition of "union smb_write" and "enum write_level" in
476 include/smb_interfaces.h. (no, don't just skip reading it, really go
477 and read it. Yes, that means you!).
479 Notice the union? That's how Samba4 allows a single NTVFS backend
480 interface to handle the several different ways of doing a write
481 operation in the SMB protocol. Now lets look at one section of that
484 /* SMBwriteX interface */
486 enum write_level level;
502 see the "in" and "out" sections? The "in" section is for parameters
503 that the SMB client sends on the wire as part of the request. The smbd
504 front end parse code parses the wire request and fills in all those
505 parameters. It then calls the NTVFS interface which looks like this:
507 NTSTATUS (*write)(struct request_context *req, union smb_write *io);
509 and the NTVFS backend does the write request. The backend then fills
510 in the "out" section of the writex structure and gives the union back
511 to the front end (either by returning, or if done in an async fashion
512 then by calling the async send function. See the async discussion
513 elsewhere in this document).
515 The NTVFS backend knows which particular function is being requested
516 by looking at io->generic.level. Notice that this enum is also
517 repeated inside each of the sub-structures in the union, so the
518 backend could just as easily look at io->writex.level and would get
521 Notice also that some levels (such as splwrite) don't have an "out"
522 section. This happens because there is no return value apart from a
523 status code from those SMB calls.
525 So what about status codes? The status code is returned directly by
526 the backend NTVFS interface when the call is performed
527 synchronously. When performed asynchronously then the status code is
528 put into req->async.status before the req->async.send_fn() callback is
531 Currently the most complete NTVFS backend is the CIFS backend. I don't
532 expect this backend will be used much in production, but it does
533 provide the ideal test case for our NTVFS design. As it offers the
534 full capabilities that are possible with a CIFS server we can be sure
535 that we don't have any gaping holes in our APIs, and that the front
536 end code is flexible enough to handle any advances in the NT style
537 feature sets of Unix filesystems that make come along.
543 In Samba3 we supported just one process model. It just so happens that
544 the process model that Samba3 supported is the "right" one for most
545 users, but there are situations where this model wasn't ideal.
547 In Samba4 you can choose the smbd process model on the smbd command
551 DCERPC binding strings
552 ----------------------
554 When connecting to a dcerpc service you need to specify a binding
559 TRANSPORT:host:[flags]
561 where TRANSPORT is either ncacn_np for SMB or ncacn_ip_tcp for RPC/TCP
563 "host" is an IP or hostname or netbios name
565 "flags" can include a SMB pipe name if using the ncacn_np transport or
566 a TCP port number if using the ncacn_ip_tcp transport, otherwise they
567 will be auto-determined.
569 other recognised flags are:
571 sign : enable ntlmssp signing
572 seal : enable ntlmssp sealing
573 validate: enable the NDR validator
574 print: enable debugging of the packets
575 bigendian: use bigendian RPC
578 For example, these all connect to the samr pipe:
581 ncacn_np:myserver:samr
582 ncacn_np:myserver:samr,seal
583 ncacn_np:myserver:\pipe\samr
584 ncacn_np:myserver:/pipe/samr
585 ncacn_np:myserver[samr]
586 ncacn_np:myserver[\pipe\samr]
587 ncacn_np:myserver[/pipe/samr]
588 ncacn_np:myserver:[samr,sign,print]
589 ncacn_np:myserver:[\pipe\samr,sign,seal,bigendian]
590 ncacn_np:myserver:[/pipe/samr,seal,validate]
592 ncacn_ip_tcp:myserver
593 ncacn_ip_tcp:myserver:1024
594 ncacn_ip_tcp:myserver[1024]
595 ncacn_ip_tcp:myserver:[1024,sign,seal]
598 IDEA: Maybe extend UNC names like this?
600 smbclient //server/share
601 smbclient //server/share:[sign,seal,spnego]
605 The various handles that are used in the RPC servers should be created and
606 fetch using the dcesrv_handle_* functions.
608 Use dcesrv_handle_new(struct dcesrv_connection *, uint8 handle_type) to obtain
609 a new handle of the specified type. Handle types are unique within each
612 The handle can later be fetched again using
613 struct dcesrv_handle *dcesrv_handle_fetch(struct dcesrv_connection *dce_conn, struct policy_handle *p, uint8 handle_type)
614 and destroyed by dcesrv_handle_destroy(struct dcesrv_handle *).
616 User data should be stored in the 'data' member of the dcesrv_handle struct.
626 - command line handling
635 - use _p talloc varients
637 don't zero structures! avoid ZERO_STRUCT() and talloc_zero()
640 GMT vs TZ in printout of QFILEINFO timezones
642 put in full UNC path in tconx
644 test timezone handling by using a server in different zone from client
646 don't just use any old TALLOC_CTX, use the right one!
648 do {} while (0) system
650 NT_STATUS_IS_OK() is NOT the opposite of NT_STATUS_IS_ERR()
652 need to implement secondary parts of trans2 and nttrans in server and
655 add talloc_steal() to move a talloc ptr from one pool to another
657 document access_mask in openx reply
659 check all capabilities and flag1, flag2 fields (eg. EAs)
661 large files -> pass thru levels
663 setpathinfo is very fussy about null termination of the file name
665 the overwrite flag doesn't seem to work on setpathinfo RENAME_INFORMATION
667 END_OF_FILE_INFORMATION and ALLOCATION_INFORMATION don't seem to work
670 on w2k3 setpathinfo DISPOSITION_INFORMATION fails, but does have an
671 effect. It leaves the file with SHARING_VIOLATION.
673 on w2k3 trans2 setpathinfo with any invalid low numbered level causes
674 the file to get into a state where DELETE_PENDING is reported, and the
675 file cannot be deleted until you reboot
677 trans2 qpathinfo doesn't see the delete_pending flag correctly, but
680 get rid of pstring, fstring, strtok
682 add programming documentation note about lp_set_cmdline()
684 need to add a wct checking function in all client parsing code,
685 similar to REQ_CHECK_WCT()
687 need to make sure that NTTIME is a round number of seconds when
688 converted from time_t
690 not using a zero next offset in SMB_FILE_STREAM_INFORMATION for last
691 entry causes explorer exception under win2000
694 if the server sets the session key the same for a second SMB socket as
695 an initial socket then the client will not re-authenticate, it will go
696 straight to a tconx, skipping session setup and will use all the
697 existing parameters! This allows two sockets with the same keys!?
700 removed blocking lock code, we now queue the whole request the same as
701 we queue any other pending request. This allows for things like a
702 close() while a pending blocking lock is being processed to operate
705 disabled change notify code
715 client library and test code
716 ----------------------------
718 convert client library to new structure
719 get smbtorture working
720 get smbclient working
721 expand client library for all requests
722 write per-request test suite
723 gentest randomised test suite
724 separate client code as a library for non-Samba use
728 add remaining core SMB requests
732 fix auth models (share, server, rpc)
733 get net command working
734 connect CIFS backend to server level auth
737 reconnect printing code
738 restore removed smbd options
739 add smb.conf macro substitution code
740 add async backend notification
741 add generic timer event mechanism
747 new server models (break 1-1)
748 test clustered models
749 add fulcrum statistics gathering
git.samba.org / samba.git / blob