A unix-windows-samba sync problem

Neil Hoggarth neil.hoggarth at physiol.ox.ac.uk
Fri Oct 27 10:28:53 GMT 2000

On 27 Oct 2000, Lorenzo Corradini wrote:

>  The user (USER) creates with vi a text file (version 1.0) in his home
>  directory on the linux server. Then USER goes on the PC and tries
>  to access (through samba) to his home directory. It works and with
>  notepad USER can also open the text file created before with vi (version 1.0)
>  Now USER modifies with vi the text file to obtain version 1.2 (for example).
>  Now if USER goes again back to the Win95 PC and opens with notepad the
>  text file he still sees version 1.0. Why?

"Opportunistic Locking", aka "oplocks".

The Windows machine has asked the Samba server if it is okay to cache
the file locally, and Samba has given permission. Samba knows if someone
else touches the file *via Samba*, and sends notification to the client
that the cached version is out of date (an oplock break message).
Unfortunately, Samba doesn't (normally) have a way of knowing if some
other Unix process opens the file.

If real time synchronization between the files as seen by Unix processes
and as seen by Samba clients is important then you should turn off
oplocks on the share in question (check the smb.conf man page).

Alternatively, there is a facility called "kernel oplocks", whereby the
Samba and the kernel collaborate and Samba *does* issue an oplock break
if another Unix process opens a file. This is only available with a few
Unix kernels which have had the appropriate hooks added. Recent IRIX
6.5.x ("feature stream" rather than "maintanence stream") is the only
one I know of for sure, and I don't know whether Linux has them or not.

Neil Hoggarth                                 Departmental Computer Officer
<neil.hoggarth at physiol.ox.ac.uk>                   Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK

More information about the samba mailing list