[Samba] A samba locking question

[Thomas Hannan]

The builds themselves are done in an NFS mount 
ls -l :
/usr/local/src/samba-3.0.1 -> /var/archive/globauth/samba-3.0.1
mount :
triton:/var/archive on /var/archive type nfs
(rw,vers=3,wsize=16384,rsize=16384,hard,intr,addr=192.168.1.50)

could it possibly be executing the tests in /tmp, or maybe could this
actually be a bug in the configure test? 

I don't know if there are still any bugs in Redhat's build environment,
but just in case, the machine that I'm building Samba on is a RH7.3
system with the latest glibc 2.2.5-34 patch that RH issued, gcc 2.96-110
and a slightly older kernel (2.4.18-3). I don't have a Debian or any
other *nix server here for that matter to test on. 

Thanks,
Thomas

On Mon, 2004-02-02 at 14:08, Jeremy Allison wrote:
> On Mon, Feb 02, 2004 at 02:12:16PM -0600, Thomas Hannan wrote:
> > 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...
> 
> You could try doing the configure in the NFS mounted directory. I think
> configure runs the tests in the current directory. Then the 64-bit locking
> tests should fail and Samba should set itself up as only supporting
> 32-bit signed locks.
> 
> Jeremy.