Funny caching problem (PR#7530)

[Jeremy Allison]

eauth at softsys.co.at wrote:
> 
> I have just experienced the same problem in 1.9.18p7 after upgrading from
> 1.9.17p1 on Linux 2.0.32. The problem seems to appear when I read files
> from an MS-DOS application. The files are created/updated under Linux.
> When the files are changed or even deleted (!) on the Linux server, the
> DOS application still gets the old version. Below is my smbstatus output
> that shows the affected files:
> 
> Locked files:
> Pid    DenyMode   R/W        Oplock           Name
> --------------------------------------------------
> 14611  DENY_DOS   RDONLY     EXCLUSIVE+BATCH
> projects/sl9000/v251.be/rom2.bin   Thu Jun  4 20:09:31 1998
> 14611  DENY_DOS   RDONLY     EXCLUSIVE+BATCH
> projects/sl9000/v251.be/rom1.bin   Thu Jun  4 20:09:19 1998
> 
> Share mode memory usage (bytes):
>    102008(99%) free + 304(0%) used + 88(0%) overhead = 102400(100%) total
> 
> The behaviour is perfectly reproducable (It happens always). Any help
> would be greatly appreciated.
> 
> -Erwin
> 
> On Donnerstag, 4. Juni 1998 20:02, samba at samba.anu.edu.au wrote:
> >
> > Hi folks,
> >
> > I am experiencing a strange problem with 1.9.18p7 on FreeBSD 2.2.2.
> >
> > When I access files from the [homes] share, my Win95 client seems to be
> > caching the files, and not realising that the files may have changed.
> >
> > For example, I can load a simple text file (from the [homes] share)
> into
> > Codewright on the Win95 client. Then I edit the same file using vi on
> the
> > samba server, and write out the changes. Now, if I close the file in
> > Codewright, and re-open it, the old version of the file re-appears.
> Notepad.
> > exe shows the same behaviour, although (oddly), reading the file with
> > Quickview.exe seems to fetch the latest version every time. Once this
> is
> > done, Notepad.exe and Codewright can also load the latest version,
> (until I
> > make another change to the file).
> 

You are hitting the oplock code, which allows the client
to cache copies of files with a callback guarentee from
the Samba server. Samba cannot provide this callback protection
from access via a UNIX process (other than Samba) without
UNIX kernel changes.

To fix this problem add the line

oplocks = no

in the share section containing the files you wish to
share between the DOS and UNIX applications. Note that
this will slow access to this share somewhat.

Hope this helps,

	Jeremy Allison.
	Samba Team.


-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------