A unix-windows-samba sync problem

[Mike Brodbelt]

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? 

Oplocks. When you opened the file with notepad the first time, thw
client requested and obtained an oplock from Samba. The file data was
cached locally, and on the subsequent open you were shown the cached
data. Using vi did not cause Samba to break the oplock, so the Windows
client thought that the file was unchanged, and it was safe to show you
the cached data.

>  The file is changed and he still
>  sees the first version of the file. Now, if USER selects the file and chooses
>  "property" and opens the file with notepad he sees version 1.2. Again, why?

You broke the oplock, by forcing a read of data that was not already
cached.

>  Why he sees the new version of the file only after the "property" selection?
>  For example, the F5 (refresh) action has not the same effect.
> 
>  The problem is mission critical for me because in a more complex case, vi
>  is a unix software that creates text files that have to be read and
>  elaborated in real time by another software running on Win95. Well, the
>  software on Win95 doesn't read the last modified file created in unix.

Disable oplocks in Samba. You'll take a performance hit, but for what
you're trying to do, you have no other option. It's also worth pointing
out that if you're trying to interoperate between Unix and Windows
applications like this, you  may have problems with line end
conventions.

HTH

Mike.