Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
vorlon at netexpress.net
Sat Jun 1 10:00:02 GMT 2002
On Sat, Jun 01, 2002 at 06:49:54AM -0400, Green, Paul wrote:
> jra at samba.org [mailto:jra at samba.org] writes:
> > On Fri, May 31, 2002 at 05:50:58PM -0700, Matt Seitz wrote:
> > > From: jra at samba.org [mailto:jra at samba.org]
> > > >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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020601/504b0ea6/attachment.bin
More information about the samba-technical