DBase File locking issues (PR#20441)

[Jeremy Allison]

Jim Morris wrote:
> 
> Actually, even according to the Borland C++ 3.1 manual (old!), the
> offset is a long (signed 32 bit). The PC test program I have now shows
> the offset being locked as -268435458.  I now have the following debug
> output from Samba, in log level 10, that shows the problem. Appears
> the fcntl call to lock the file region is failing in either the C
> library or Linux kernel....  Also note that Samba at least is treating
> the lock offset as an unsigned long, rather than a signed long.
> 
> [1999/09/16 14:03:25, 10] locking/locking.c:remove_share_oplock_fn(246)
>   remove_share_oplock_fn: removing oplock info for entry dev=801 ino=239624
> [1999/09/16 14:03:25, 10] smbd/reply.c:reply_lockingX(4252)
>   reply_lockingX: lock start=4026531839, len=1 for file cbtest/cbtest.DBF
> [1999/09/16 14:03:25, 10] locking/locking.c:do_lock(113)
>   do_lock: lock type 1 start=4026531839 len=1 requested for file cbtest/cbtest.DBF
> [1999/09/16 14:03:25, 8] lib/util.c:fcntl_lock(2676)
>   fcntl_lock 8 6 4026531839 1 1
> [1999/09/16 14:03:25, 3] lib/util.c:fcntl_lock(2702)
>   fcntl lock gave errno 22 (Invalid argument)
> [1999/09/16 14:03:25, 3] lib/util.c:fcntl_lock(2724)
>   lock failed at offset 4026531839 count 1 op 6 type 1 (Invalid argument)
> [1999/09/16 14:03:25, 3] lib/util.c:fcntl_lock(2729)


>   locking not supported? returning True

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This above is old crufty code that is no longer needed; it was
used for systems that didn't have fcntl locks. We now check
for these at compile time and refuse to run. I'm removing
this asap.

> [1999/09/16 14:03:25, 3] smbd/reply.c:reply_lockingX(4290)
>   lockingX fnum=4880 type=2 num_locks=1 num_ulocks=0
> [1999/09/16 14:03:25, 5] lib/util.c:show_msg(459)
> 
> Note that after the lock failure, Samba decided to return a TRUE
> result!  Ouch....   That explains why both clients think they got the
> lock, when the lock actually failed!
> 
> I'm looking at the kernel source file linux/fs/locks.c right now,
> trying to determine what the "invalid argument" was.  I've not quite
> figured it out at this point.

I think I know what is going on. Bloody glibc2.1 and it's
64 bit claims again..... I need to do some tests on a proper
64 bit system and on a 32 bit system (Linux) - unfortunately
Linux claims to be 64 bit with glibc2.1 on intel hardware.

> Sure!  If you want, I can quickly email you a test DOS executable, and
> some small DBase files to test against.

That would help, but not quite yet I think. I think I have
a handle on this problem, I'll get back to you soon.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------