ksh UWIN 1.6 and samba shares problem

[Gerald Carter]

Hmmm....

I cc'd this to samba-technical.  The original message follows my
signature.

Here's what I have noticed.

Prior to NT SMB support

- The client would send an TRANS2_QUERY_FS_INFORMATION with the
information level set to 0x02
- The samba server would respond correctly.
- The client would send a TRANS_QUERY_PATH_INFORMATION...

Against a samba server with NT SMB's

- The client would send an TRANS2_QUERY_FS_INFORMATION with 
  the information level set to 0x0102
- The samba server responds [but the response leaves out the 
  Volumne length and not volume string?]
- The client sends a TRANS2_QUERY_FILE_INFORMATION
- The samba server replies with an INVALID_HANDLE


Here's my question....

Looking at the code, the SMB_QUERY_FS_VOLUME_INFO code was 
what was changed to support autorun right?  Did this break 
something else possibly?

I'm still looking but if someone thinks of something, let me 
know.



j-
________________________________________________________________________
                            Gerald ( Jerry ) Carter	
Engineering Network Services                           Auburn University 
jerry at eng.auburn.edu             http://www.eng.auburn.edu/users/cartegw

       "...a hundred billion castaways looking for a home."
                                  - Sting "Message in a Bottle" ( 1979 )


=====================================================================
Hi again,

I decided to dig into the ksh-UWIN problem myself, and so far I've
only been able to narrow it down a bit.  I would really appreciate
some help on this one, or at least a definite "no, we can't work on
this now, sorry".  So far I've had no feedback one way or the other.

Once again, the problem is triggered from ksh (UWIN version 1.6) when
trying to list a directory located on a samba-served mapped network
drive (UNCs are also a problem).  It seems that with smbd as of July
1st, 1998 the transaction consists of an open_and_X call, initiated by
the client (NT4 SP3), then a nttrans2(findfirst/findnext).  With the
latest cvs'ed smbd, the transaction is initiated with an
ntcreate_and_X on the directory.  What seems weird to me is that samba
replies to the ntcreate_and_X with an apparently valid FID, but on the
next transaction (findfirst) it returns a "DOS ERROR 6, Invalid
Handle" message (as seen with NETMON).  In the case of the latest
samba, the client never gets to the findnext request.  

This causes me to wonder: how come the client initiates the
transaction with a different call (open_and_X vs ntcreate_and_X) ?  Is
there something in the protocol/dialect negotiation that tells the
client which one to use?  There wasn't anything in the NETMON trace
that lead me to believe so.

An important note: so far, while listing directories fails, accessing
other files within the share is no problem (e.g. using tail on one of
the files works just fine).  Moreover, exec'ing directories must
partially work, since I can access files that are in subdirectories of
the mapped network drive.  I still can list those subdirectories,
however, and I cannot cd to them.

Any information you guys could provide on what I should be looking for
would be much appreciated.

Thanks

Pierre

P.S. I have level-10 logs, level-100 logs, NETMON traces, all of which
were uploaded to ftp://samba.anu.edu.au/pub/upload a while back.