smbmount and smbfs (was Re: smbmount et al...)

[Luke Kenneth Casson Leighton]

On Tue, 29 Sep 1998, Michael H. Warfield wrote:

> Andrew Tridgell enscribed thusly:
> > > With regards to the timestamp problem, I would suspect that you've
> > > mounted the volume with incorrect bug-workaround flags. There are
> > > differences in the way timestamps are handled in Win95 vs NT smb
> > > servers, so if smbfs thinks it's talking to a Win95 system,
> > > timestamps will probably be wrong.
> 
> > you might like to change smbfs to look at the capabilities bits from
> > the negprot response:
> 
> > if (capabilities & CAP_NT_SMBS) {
> >   use_nt_code();
> > } else {
> >   use_win95_code();
> > }
> 
> > or should smbmount do this and pass a flag to the kernel?
> 
> 	I think the later...  Luke and I and Dave LeBlanc (my evil NT
> twin at Internet Security Systems) were discussing this today.  Dave
> thinks that doing a "GetServerInfo" at the appropriate level should
> give the information we are looking for.  There are bits which will
> identify WfWg and W95.

the call is a dce/rpc "NetServerGetInfo" call.

>  We can apply appropriate discrimination at
> the time the connection is established.  Luke had a different approach.
> He suggested opening an RPC pipe and, if that failed, then applying the
> bug work-around.  That would ALSO be at connection time.  Downside to Luke's
> approach would be if someone added that capability to Win95 (YUCK).

no, that's also ok.  the pipe opening is part of doing the
"NetServerGetInfo" call.  the thing is that this is what i have observed
ms systems doing: just opening "\PIPE\srvsvc" or "\PIPE\lsass" not sure
which and then closing it.

heck, if microsoft want to add dce/rpc code to win98, good luck to them:
they'll have to find the solution to this problem and then we just watch
on the wire what they did and follow suite.