(Correction) File caching while "oplocks=False", black magic or what?

Yannis Tzavellas hypersft at otenet.gr
Sat Nov 27 22:32:23 GMT 1999

This is a corrected version of an incorrect message sent previously.
*Sorry for this*.
This message replaces references to lock (in the old message) with
lseek. (Actually locking problems have a special position in my mind, at
least for the last 3-4 years, when I am programming in heterogenous
networks. But that's another story...)


NOTE: I have definitely put "oplocks=False" in my smb.conf.

I use a program running on 2 machines (win95 and win98) to access data
on my samba server (samba 2.0.3-8, on Redhat 6.0). The programs, when
accessing data on the server, go like this:

int get_record(..)           int put_record(..)
{                            {
  if (lseek(...)) {             if (lseek(...)) {
    if (read(...)) {              if (write(...)) {
      ....                           ....
    } else ...                    } else ...
  } else ...                    } else ...
}                            }

i.e they simply position the file and perform a read or write on it.

Files are flushed after writing. So whenever anyone of the 2 windows
clients changes a record, this change is actually stored in samba. (A
linux-version of the "client" program that runs on the Linux box, sees
the change.)

BUT this does't work the other way around: A change performed by the
linux-client IS NOT SEEN by any of the windows clients. They behave
lazily on reading (as if they are caching data).

After 2 days of debugging, reading docs, drinking coffe and NOT eating
pizza (or almost anything),
.... I finaly find "a way" to get rid of the problem. But what a way it

The cure I used is absolutely incomprehensible to me. Here it is:

==>> I just added a little delay (?) loop at the beginning of the
==>> get_record():

int get_record(..)
  // this little delay (?) loop seems to cure the problem
  for (int i=0; i<4; i++) { // 4 or more works, 3 does't !
    lseek(fh, 0L, 0);        // fh = the file handle
    read(...);              // no matter what. I read 10 bytes
  // nothing else touched anywhere...

  if (lseek(...)) {
    if (read(...)) {
    } else ...
  } else ...

and after this everything seems to work fine !

So my questions are:
1. Why windows clients insist to cache data despite of "oplocks=False" ?

2. Does anybody understand what is going on with my "solution" and how
it actualy manages to force the clients NOT to cache

Thanks again !

-------------- next part --------------
HTML attachment scrubbed and removed

More information about the samba mailing list