something to bear in mind here is that TID's and FID's are assigned on a
per-session basis, and are only valid for that session/tree connection.
this is in stark contrast to the concept of filehandles for NFS, which
are algorithmically generated, and can be converted back to a filesystem
and inode on most systems.
sucks to be stateful, don't it?
nathan
On 18 May, Alan Harrison wrote:
> Thanks for the reply,
>
> Just to clarify what I was asking: I have been capturing SMB packets on my
> system and noticed that if I missed the start of a file open I was not able
> to identify the share, file or process which the TIP,PID etc fields related
> to on the client or server.
> What I was hoping to do was to associate these values with processes,
> shares, files etc from the NT client or Server point of view. So if I catch
> a packet and the TID is say AB23, I can run a utility on the server or
> client side which will say TID AB23 is share \\server\files (or drive p:
> say).
> This information will be held on the client and server somewhere so that it
> can respond to the received packets. I presume this is buried deep in the
> low level networking code and there is no way to access it. I've looked
> through the MSDN stuff and I can't find any reference to it there.I've also
> looked at the utilities on www.sysinternals.com which are pretty good on
> filehandles, tcp ports etc but nothing to view the SMB TID,PID stuff.
> ----
> alanharrison@xxxxxxxx