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

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

WELL, HERE IS THE CORRECTED MESSAGE:


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
is...
*/

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

==>> I just added a little delay (?) loop at the beginning of the
function
==>> 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
data?

Thanks again !

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