Unix-Windows file synchronization problem

[Sean E. Millichamp]

Hello,

On Thu, 21 May 1998, Marina Markus wrote:

> Looking for help !

I hope I can :)... sounds like a problem a coworker of mine had yesterday.

> We have a rather strange problem working with Samba installed
> on a DEC Alpha server, when reading an exported directory from Windows.
> 
> We are using an application written in C that reads a file from drive E:
> where a directory exported from Alpha is mounted. Once the file is read,
> all the further readings ignore changes in the file (file is changed
> on Alpha). Even as we read it 10 minutes after it was changed, we still
> see the old contents. The file is opened and closed every time we are
> reading, so there is no reason this should happen.

You didn't say what version of Samba you are using, but I would wager it's
one of the 1.9.18 series.  You also didn't include a smb.conf, but you
probably have "oplocks" enabled.  An "Oplock" or Opportunistic Lock, lets
the client (in this case, Windows) cache a copy of the file locally.
While you work on it, the client never updates the server, or asks for an
updated copy.  Windows 95 keeps oplocks around after the file was close
for quite a while.  When you modify a file in Unix it has no way to tell
Samba to force the oplock closed (and thus, force a read on the Windows
box) since the Unix filesystem doesn't work with Samba's oplock system.

> However, if we open a DOS window and issue a "type" command for this file,
> we always get the update contents. If afterwards we issue a read from C
> application, we also get the updated contents of the file.

My guess would be that the DOS "type" command never got much smarter from
the very old DOS days and it doesn't know how to deal with oplocks,
therefore, when you read a file with type Windows breaks the oplock, then
reads the current file from the server to display to type.  Then once back
in the C application I bet the oplock gets reacquired and everything after
that is cached again.

> Similar problem occurs with other applications (e.g. in TCL/TK).
> It looks like the application doesn't read from the remote drive, but
> from some buffer in the memory, and it is not notified properly that
> the file has changed.

Any situation where you have Windows and Unix both modifying files at the
same time is going to cause trouble if you use oplocks.  By best
suggestion is that on any share where you will be using both set "oplocks
= false" (you should double check the smb.conf man page to make sure my
syntax is correct).  Having oplocks disabled will reduce performance
(sometimes significantly) but will insure more reliable data access.  You
other solution is to issue a DOS type command if that seems to break the
oplock.

If you want to confirm this behavior run "smbstatus" on the Samba server
and it will show you all the files that have oplocks (among other useful
things). 

> I will appreciate very much any idea or experience concerning this
> problem.

I hope I helped... if any part of my explaination was unclear, please let
me know and I will try to clear it up.

> Marina Markus
> Ben-Gurion University Computer Center
> (07)6461-745
> ======================
> mary at bgumail.bgu.ac.il

Best,
Sean

------------------------------------------
 Sean E. Millichamp, Consultant
 Ingematics - A Division of Compu-Aid, Inc.