File changes not being written immediately

MCCALL,DON (HP-USA,ex1) don_mccall at
Tue Mar 27 00:23:11 GMT 2001

Hi Lance,
boy that's a wierd one.  Would you like to get a debug log at level 10 and
send it to 
me offline?  Set it up so that you log file = log.%m, and have a user
duplicate the problem, and do NOTHING else, until you confirm that the
changes have actually been written on the UX side.  then save off the log
file and send it to me with the username, and filename that you ran the test
with - maybe I'll luck out and spot something.
Hope to help,

-----Original Message-----
From: Lance Lovette [mailto:lance-samba at]
Sent: Monday, March 26, 2001 5:13 PM
To: samba at
Subject: RE: File changes not being written immediately

I added the following to the top of /etc/smb.conf:

oplocks = false
kernel oplocks = false

I observed no difference in behavior. Are there any other settings I can
try? Are there any other tests I can run to help diagnose the problem? For
what it's worth, testparm says /etc/smb.conf has the following oplocks
related settings:

kernel oplocks = No
oplock break wait time = 10
veto oplock files =
fake oplocks = No
oplocks = No
level2 oplocks = No
oplock contention limit = 2


-----Original Message-----
From: Rashkae [mailto:git at]
Sent: Friday, March 23, 2001 6:31 PM
To: Lance Lovette
Cc: samba at
Subject: Re: File changes not being written immediately

Sounds like opportunistic locking (oplocks). When a client requests an
oplock, the server grants that client exclusive use of the file. The
client uses that "exclusive" permission to cache the file locally. (if a
second client requests the file, the server sends a message to the first
client to release the lock, in which case it has to write all changes to
the server and abandone the local cache.)

>From the smbd.conf documentation:

kernel oplocks (G)
       For UNIXs that support kernel based oplocks (currently only IRIX
       but hopefully also Linux and FreeBSD soon) this parameter allows
       the use of them to be turned on or off.
       Kernel oplocks support allows Samba oplocks to be broken whenever
       a local UNIX process or NFS operation accesses a file that smbd
       has oplocked. This allows complete data consistency between
       SMB/CIFS, NFS and local file access (and is a very cool feature

oplocks (S)
       This boolean option tells smbd whether to issue oplocks
       (opportunistic locks) to file open requests on this share. The
       oplock code can dramatically (approx. 30% or more) improve the
       speed of access to files on Samba servers. It allows the clients
       to aggressively cache files locally and you may want to disable
       this option for unreliable network environments (it is turned on
       by default in Windows NT Servers). For more information see the
       file Speed.txt in the Samba docs/ directory.
       Oplocks may be selectively turned off on certain files on a per
       share basis. See the 'veto oplock files' parameter. On some
       systems oplocks are recognized by the underlying operating system.
       This allows data synchronization between all access to oplocked
       files, whether it be via Samba or NFS or a local UNIX process. See
       the kernel oplocks parameter for details.
       Default: oplocks = True
       Example: oplocks = False

On Fri, 23 Mar 2001, Lance Lovette wrote:

> Our development team has been having the following issue for quite some
> and I cannot isolate the problem. I saw a similar posting in the archives
> but there are no replies.
> We are running Samba 2.0.7 on a RedHat 6.2 server and we connect to the
> server from Windows 2000 desktops. We are editing files through a drive
> mapped to a share on the server. The problem is when we save the file in
> editor, the changes are not immediately written to disk. It can take
> anywhere from 10 to 45 seconds for the changes to appear on the server. I
> can test this by saving a file from Windows and using VI on the server.
> problem is exhibited most prominently by Allaire Homesite 4.5 but it also
> occurs less frequently in other editors we have experimented with. Any
> ideas?
> Thanks!
> Lance
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:

To unsubscribe from this list go to the following URL and read the

More information about the samba mailing list