[Samba] A samba locking question

[Thomas Hannan]

This is exactly the case -- I want it to NOT pass down a 64 bit lock to
fcntl but it does. I unfortunately have no alternative but to re-export
an NFS mount (v3 on linux), and have tried to make it fail the configure
test for 64 bit fcntl, but have not succeeded. (in the configure script,
I simply made either result of the conftest for 64 bit fcntl locking set
samba_cv_HAVE_STRUCT_FLOCK64=no) ...

even when I compile after telling it that I don't have 64bit locking, i
still get loads of errors in my syslog from smbd
locking/posix.c:posix_fcntl_lock(656) an No locks available error. This
can happen when using 64 bit offsets .... 

I wish I could find a way to not have to re-export an NFS mount, but
there's no way around it and I know that when I tested with an old 2.2
binary that it worked beautifully, but I wasn't able to use any of the
new features in 3.0, or test out new RC versions...

Would it help to attach my config.log ?

Thomas

On Mon, 2004-02-02 at 13:25, Jeremy Allison wrote:
> On Mon, Feb 02, 2004 at 01:26:01PM -0600, Thomas Hannan wrote:
> > Hello,
> > 
> > I have a question to tack on to this one -- 
> > 
> > How would I go about compiling Samba such that it either didn't pass
> > locking requests (for file shares, not TDB's) to fcntl() and just
> > handled these locks internally for the Windows clients, or at least did
> > that for locks requested in the 32-64 bit offset range? If I'm not
> > mistaken, I believe that was the default behavior in the 2.2 series, and
> > looks like it changed in 3.0.0 (at least in my tests on linux 2.4.x with
> > glibc 2.2).
> 
> Nope, Samba always handles full 64-bit unsigned locks internally. It
> then passes down the parts that make sense to the underlying lock
> system (be it 32-bit or 64-bit signed). Samba should already be doing
> this. If it isn't for you then the configure test is screwing up and
> telling Samba you have 64-bit signed fcntl locks when you really don't
> (such as when re-exporting an NFS mount for instance).
> 
> Jeremy.