details on client calls

[samba-technical.10.overbored at spamgourmet.com]

Thus spake Jeremy Allison - jra at samba.org on 8/16/2005 10:45 PM:
> On Tue, Aug 16, 2005 at 10:43:38PM -0700, samba-technical.10.overbored at spamgourmet.com wrote:
> 
>>hi all, where can i find details on what particular smb client calls do 
>>(i.e. the packets generated by the cli_* functions)? in particular, i'm 
>>trying to find out how recursive read/write locks (cli_lock()) work (as 
>>used in smbtorture test LOCK4). i can't find any info on this aside from 
>>random mailing list posts.
>>
>>hopefully this was the right list to post to. thanks in advance!
> 
> 
> The cli_lock calls make SMBlockingX calls on the wire. What do you need
> to know ?

sorry, i should have been more specific with my questions. i am 
interested in finding out about the smb messages themselves, so in this 
case, the lock semantics. e.g., why does smbtorture expect to be able to 
read in test LOCK4's subtest "this server does do recursive lock 
overlays" (torture.c:1565 in samba-3.0.14a)? wouldn't a write lock be 
exclusive, and read locks allow other read locks? basically these are 
details that (i think) seem reasonable to include on a reference (like 
msdn or man pages). or, if anybody can answer that question here... :)

(a later subtest in the LOCK4 test, "the same process does remove the 
first lock first", is also giving me grief.... so recursive locks are 
fifo? i guess that would explain the above....)

another specific question i had was regarding the DELETE torture test. 
what exactly are "nt api" and trans/trans2 calls, and where can i learn 
more about them?

i'm running the OPEN test on a regular windows 2000 share, and it's 
failing when i enable the -L for oplocks. this is what the test appears 
to be doing:

- create (and close) a file

- set the read-only attribute
- open the file read-only
- open the file read-write, expecting failure ERRnoaccess [B]
- close the (read-only) handle

- clear the read-only attribute
- open the file read-only, with share mode deny-write
- open the file read-write, expecting failure ERRbadshare [A]
- close the (read-only) handle

- delete the file
- re-create the file
- write to the file
- close the file
- get the file's attributes and check the size
- truncate the file
- get the file's attributes and check the size

the item in the above procedure labeled "[A]" returns NT_STATUS_OK, 
meaning the file open succeeded. in another case, where one of the 
drives is actually a remote (SAN) mount, [B] fails, because we get 
ERRbadshare (NT_STATUS_SHARING_VIOLATION) instead of ERRnoaccess. I'm 
wondering what the meaning is behind ERRbadshare, and why ERRnoaccess 
should always dominate ERRbadshare (perhaps in this case of sharing a 
SAN mount, returning ERRbadshare was correct?).