Yannis Tzavellas
2003-12-01 17:13:46 UTC
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 (lock(...)) { if (lock(...)) {
if (read(...)) { if (write(...)) {
.... ....
} else ... } else ...
} else ... } else ...
} }
i.e they simply lock 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:
==>> I just added a little delay (?) loop at the beginning of the
==>> get_record() function as in :
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 !
lock(fh, 0L, 0); // fh = the file handle
read(...); // no matter what. I read 10 bytes
}
// nothing else touched anywhere...
if (lock(...)) {
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 !
-------------- next part --------------
HTML attachment scrubbed and removed
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 (lock(...)) { if (lock(...)) {
if (read(...)) { if (write(...)) {
.... ....
} else ... } else ...
} else ... } else ...
} }
i.e they simply lock 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:
==>> I just added a little delay (?) loop at the beginning of the
==>> get_record() function as in :
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 !
lock(fh, 0L, 0); // fh = the file handle
read(...); // no matter what. I read 10 bytes
}
// nothing else touched anywhere...
if (lock(...)) {
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 !
-------------- next part --------------
HTML attachment scrubbed and removed