samba - Feb 1999 - Problem with Samba caching file contents

Hello everybody,
We are using Samba 2.02 on Sun Solaris 2.51 and 2.6 platforms.
Using these as a file server we occasionally have the following 
problem:
- the file is changed on the file server using standard UNIX tools 
while somebody else is editing it
- the other user re-loads the file using a Windows 95 client
- the content of the file seems to be the same as before the change 
on the windows client, but is definitively not, if you look at the 
server side

This implies to me, that there must be some kind of caching 
algorithm implemented in samba, that does not cover the server-
side changes of files - or at least sometimes misses them.

- how can I disable this cache?
- we are using Ultraedit on the clients for editing files - is there any 
known issue maybe using this tool or Windows 95 itself ?
- any other ideas, that could help?

Thanks in advance!

Frank Kettenbeil
Mit freundlichen Gruessen
Frank Kettenbeil

Danet GmbH
Geschaeftsstelle Telekommunikationstechnologie (TT)
Telefon: 06151 868-190           Fax: 06151 868-264
Email: kettenbeil@danet.de

On Fri, 12 Feb 1999, Frank Kettenbeil wrote:
> Hello everybody,
> We are using Samba 2.02 on Sun Solaris 2.51 and 2.6 platforms.
> Using these as a file server we occasionally have the following 
> problem:
> - the file is changed on the file server using standard UNIX tools 
> while somebody else is editing it
> - the other user re-loads the file using a Windows 95 client
> - the content of the file seems to be the same as before the change 
> on the windows client, but is definitively not, if you look at the 
> server side
> 
> This implies to me, that there must be some kind of caching 
> algorithm implemented in samba, that does not cover the server-
> side changes of files - or at least sometimes misses them.
What you are experiencing is opportunistic locking (or oplock).  The
problem is that Windows generally (always?) requests an oplock for a file
that you open.  This can be very good because this means Windows keeps it
cached locally.  If another Windows client accesses the file then Samba
breaks the oplock which forces the Windows client to flush the cache. As
you have seen, this can also be bad since Samba on most platforms
(currently all except IRIX) can't tell when a file is modified under Unix
and therefore does not know to issue an oplock break, resulting in the
file staying cached at the Windows client.

In Samba 2.0.x there is a mechanism by which the kernel can signal to
Samba that it needs to break the oplock, which is what IRIX uses, but you
will either have to switch OSs or bug Sun into integrating it into their
next release of Solaris.  For the Linux and *BSD crowd kernel oplock
support is expected to appear relatively shortly (having the source is
nice:)).

You can disable it on a share by share basis with "oplocks = no".
Disabling oplock support will probably produce a very noticable slow down
in whatever Samba shares you apply it to so I suggest using it only when
necessary.

For more information about the various oplock options you can do a search
for "oplock" in the smb.conf man page.

I hope this helps.

Best,
Sean

------------------------------------------
 Sean E. Millichamp, Consultant
 Ingematics - A Division of Compu-Aid, Inc.