RE: CLIPPER LOCKS (again)

[Greg LaBossiere <solutions@xview.com>]

On Friday, July 12, 2002 12:37 PM, Anderson Pereira Ataides 
[SMTP:anderson.pa@persogo.com.br] wrote:
> Hello,
>
> Again I'm asking for help, because I did not fix my problem. 
Remembering
> my story is that I have an application written using Clipper 5.2 and 
when
> a workstation with linux+dosemu opens a file and lock a record (or the
> entire file), another workstation running Windows still can open that
> file, meaning that it can't see the file is locked by dosemu. Trying 
this
> operation opening the file in Windows first, the problem still occurs.
>
> I upgraded kernel to 2.4.18 but problem is still there.
>
> I'm using:
> 	kernel 2.4.18
> 	samba 2.2.0
> 	dosemu-1.1.2
>
> Mr Sergey Suleymanov sent me a message telling me to use a fix (see
> below) but I did not understand it. How am I supposed to use this fix?
> Do I have to type it at linux prompt? Is it a script? Is it something 
to
> put into a configuration file?
>
> Greg LaBossiere also sent me a message suggesting to upgrade kernel. So
> I did it but did not solve my problem.

After upgrading Linux kernel and SAMBA, you also need to tune the SAMBA 
oplocks settings. Refer to 
http://de.samba.org/samba/ftp/docs/htmldocs/using_samba/ch05_05.html

Here's a short quote:

"Windows systems cooperate well to avoid overwriting each other's 
changes. But if a file stored on a Samba system is accessed by a Unix 
process, this process won't know a thing about Windows oplocks and could 
easily ride roughshod over a lock. Some Unix systems have been enhanced 
to understand the Windows oplocks maintained by Samba. Currently the 
support exists only in SGI Irix 6.5.2f and later; Linux and FreeBSD 
should soon follow. [Note: Linux kernel 2.4+ has oplocks support].

If you have a system that understands oplocks, set kernel oplocks = yes 
in the Samba configuration file. That should eliminate conflicts between 
Unix processes and Windows users.

If your system does not support kernel oplocks, you could end up with 
corrupted data when somebody runs a Unix process that reads or writes a 
file that Windows users also access."

I do not recommend using the "veto oplock files" directive. As the 
authors point out, it is "a rough protection mechanism" and should not be 
considered reliable in all circumstances.

BTW, I highly recommend O'Reilly's "Using Samba" by Eckstein, 
Collier-Brown and Kelly... it's an excellent reference.

Greg LaBossiere
XVIEW SOLUTIONS INC.
mailto:greg.labossiere@xview.com