As I mentioned earlier today we managed to find out a solution to our
problems.


I am running RH 8 with Samba 3.0.5

1) No samba shared mounted on Linux (this way I avoid smbfs)

2) Parameters in smb.conf for the share:
-locking = yes
-veto oplock files = *.dat/*.k*/*.hdr (in my case)
-strict locking = no


That last parameter seems to be the one that avoided writing new records
to a file by the windows program while that same file was open by the
Linux program.


On the other hand, we just finished one last test with 4 programs (2 in
linux, 2 in Win) accessing the same file and writing to it
simultaneously. Other two programs kept that file open: one in linux and
the other in Win.
We wrote and read well over 10.000 new records without problems. Locks
were respected, file was not damaged, and records were all recorded. So
it seems that finally we are on the right track!

If we have time we will write another set of programs to go on a loop
and keep them alive for a few hours. We will try with 24 sessions open
in Linux and as many as possible in Win.

We will let you know how it went when we finish.

Regards.


On Wed, Sep 15, 2004 at 10:52:56AM -0500, Christopher R. Hertel wrote:
> Okay, so...
>
> Based on the info Andrew provided and some of the other comments in
> this
> thread, it seems that the problem is:
>
> - Linux/Posix supports locking semantics that are different from those


> used by Windows.
>
> I knew, generally, this was a problem but I wasn't quite sure how

much
> of a problem it was. Seems to be bigger than I thought. The issue

here
> is two-fold. First, the Linux client needs to translate locking
> semantics to match the needs of CIFS. Next, the Samba server needs

to
> translate to Posix semantics for all clients. Ouch.


Yers, but we do this correctly. So in general there isn't a problem. The
issue is usually that the more clients you have writing into a shared
file the more critical it is the clients are stable. And mostly Samba is
serving Windows clients, so.......

:-(.

Jeremy.