Clipper locking

[Elvis Pfutzenreuter]

> 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.

So my guess is probably right (i.e. it is really a client issue)

The stangest thing is, since I have first written to samba-technical, I have 
been running a Clipper program tailored to stress locking, and I have had *no 
corruption problems* since yesterday. I am really believing it is a client 
issue, since the client machines in my test farm are Win95 OSR2 (came with 
the Fujitsu E330 notebook, it is w95 but heavily patched so none of the 
'normal' w95 bugs don't appear) and a w98r2. 

> 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.

AFAIK dBase and Clipper really use this dirty trick. Translating that to a 
valid lock range is a client issue, eh ?