Clipper locking

[Paul Heinz]

Tim wrote:
> > I think that's it, Mike.  At the CIFS conference there was some
> > issue with overlapping byte range locking in opportunistic
> > locks.  I don't have specifics but it was being worked on.  On
> > the plus side, the new tools that Tridge has been building for
> > testing these things should help find these bugs sooner, and
> > not just in Samba code but in many third-party vendor's code.
>
> It definitely sounds like a locking bug in Samba.  Hopefully the
> next release, version 2.2, should have much better (perhaps even
> completely correct) locking support.
>
> It sounds like the clipper client relies heavily on correct NT
> locking semantics which every previous version of Samba did not
> have.

Whilst I'm not disagreeing, it should also be known that there were a number
of lockings bug in the VREDIR component of Win95 which could also cause
these symptoms. What VREDIR version do the client machines in question have?
The version with the fixes is 4.00.1116 - anything earlier than that has a
number of client side caching issues which can result in corrupt data since
the client will read stale data from it's cache rather than reading from the
server (whether it's Win95, WinNT or Samba). An updated VREDIR can be
downloaded from MS or I could email you the patch.

Is clipper locking the _exact_ byte region it is trying to read? The reason
I ask is that some dBase derivatives (FoxPro for example) used a form of
'ghost' locking where they lock bytes 2G further down the locking region
i.e. beyond the end of the file rather that the 'real' bytes to work around
the DOS limitation that locks couldn't be read under on older PCNET/MSNET
based networks.

This was all fine and dandy until Win95 VREDIR added an 'optimisation'
whereby unless a region of byte were locked, VREDIR could return a cached
value from it's internal cache rather than reading from the server.

TTFN,
  Paul.