[jcifs] Very minor oddity testing SmbComTreeConnectAndX.java

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> 
> > > PS.  As far as I can tell W/95 ignores that bit in a TreeConnect... which 
> > >      makes sense.  Why would there be a disconnect bit in a tree connect 
> > >      request?  Am I missing something or is this just silliness in the
> > >      SMB?
> > > 
> > 	It means after servicing the AndX message to disconnect. It's an
> >       optimisation; in one operation you can tree connect, perform some
> >	command (e.g. delete), and then disconnect.
> 
> So, if I understand correctly, the disconnect is delayed until the end of
> the AndX chain.
> 
> In an AndX block like this:
> 
>   {
>   SessionSetupAndX
>   TreeConnectAndX (disconnect == true)
>   CreateAndX
>   }
> 
> the disconnect would actually follow the CreateAndX block.  If that's the 
> way it works, that makes sense.  I suppose it is also useful to have a 
> block like:
> 
>   {
>   SessionSetupAndX
>   TreeConnectAndX (disconnect == true)
>   }
> 
> Which would verify that you had permission to connect, but not return an 
> open TID.
> 
> Am I close here?
> 
	I have never tested the disconnect Tid functionality but consider that the AndX
	messages are concatenated one after the other in one SMB so there is no well
	defined point at which you're "disconnected". Naturally one must be "connected" to
	process the request but ultimately you know that when the disconnectTid flag is
	set, when you receive the response you're now "disconnected". Incidentally this
	means that jCIFS would have to be modified to properly support the disconnectTid
	functionality because it would have to delete the SmbTree on the trees list or it will
	still think it's "connected" and get errors on submitting additional requests (at least
	it should although that's the kind of thing Samba wouldn't care about).