Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS

Steve Langasek vorlon at
Sat Jun 1 10:00:02 GMT 2002

On Sat, Jun 01, 2002 at 06:49:54AM -0400, Green, Paul wrote:
> jra at [mailto:jra at] writes:
> > On Fri, May 31, 2002 at 05:50:58PM -0700, Matt Seitz wrote:
> > > From: jra at [mailto:jra at]
> > > >The only thing would be to completely disallow
> > > >connection timeouts for Win9x clients - I'm not sure
> > > >this is what we want.....

> > > Perhaps timeouts could be prevented for a 9x client when an 
> > > oplock is present?  Or have two timeouts:  a shorter (soft)
> > > timeout when an oplock is not present and a longer (hard)
> > > timeout even when an oplock is present?

> > No, you can't time out at all. Remeber, as soon as you
> > time out and drop the connection (TCP RST or FIN) you're
> > dead - the client will exhibit this bug.

> > There is no way around this with different timeouts, it's
> > very simple - drop a connection to a Win9x client, suffer
> > an oplock break bug in the client. No other way around this
> > client bug.

> Is there a way to identify a Win9x client in the datastream?  If so, then
> Samba could leave the connection up for these clients....

The real bogosity of this Win9x bug is that things *not* at the
application level can cause the TCP connection to close, such as
intermittent connectivity to a WAN fileserver.  Although you may be able
to address /most/ problems by asking Samba to never shut down the
connection, there will still be connection shutdowns that Samba can't
control.  SMB clients are SUPPOSED to recover gracefully from such

Steve Langasek
postmodern programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :

More information about the samba-technical mailing list