tdb corruption with "use mmap=false"

[MCCALL,DON (HP-USA,ex1)]

Hi Jeremy,
Thanks for the clarification.
I guess what I'm concerned about is Lotus Notes, or other programs that are
'cheating' if you will, and trying to use a byte range lock beyond the end
of file at a specific position to 'communicate' something to other instances
of the program.  If this is the case, then the 1st instance will think it
has 'communicated', but when another instance does the same thing, and
doesn't fail, will think it is able to do something to the file that it
shouldn't be allowed to.

I have asked reinout if he would get a netmon or etheral trace of the action
that is generating these calls, to try to figure out if this is what is
happening; but I cannot see why a program would try to put a lock on a file
if it didn't expect someone else to be 'warned off' by that lock.

The other thing that is suspicious to me about this particular case
(reinout's Lotus notes issue) is that the 
initial offset just always HAPPENS to be 0xFFFF0000, where all the set bits
fit into the OffsetHigh smb field.
I'd like to see an ethereal or netmon trace of lotus notes on a 32bit as
opposed to the 64 bit machine, to see what it's sending in both cases...

Just being my normal paranoid self,
Thanks again,
Don

-----Original Message-----
From: Jeremy Allison [mailto:jeremy at valinux.com]
Sent: Friday, September 07, 2001 2:10 PM
To: MCCALL,DON (HP-USA,ex1)
Cc: 'jra at samba.org'; 'samba-technical at lists.samba.org'
Subject: Re: tdb corruption with "use mmap=false"


"MCCALL,DON (HP-USA,ex1)" wrote:
> 
> Hi Jeremy,
> I pulled the patch; and it will probably 'fix' reinout's problem with
lotus
> notes, BUT - if I'm reading this right, if the offset (not the count) is >
> 31 bits, we return success, but never actually try the fcntl lock.
> Isn't this going to be a problem when we are really counting on an fcntl
> lock on the file?  What am I missing?

No this isn't a problem. If the underlying NFS mount cannot
support locks with a start offset of >31 bitsthen we cannot
try the lock - it will fail. But by the same token, as such
a lock cannot exist on that filesystem then other processes
can never see or conflict with such a lock (by definition
it can't exist). So just pretending it worked w.r.t. the
64 bit unsigned Windows clients is correct. This is the
same thing we do when simulating 64 bit unsigned locks on
a local filesystem with 31 bit signed posix locks. The
only difference is that because of the dynamic nature
of NFS mounts we need to deal with this at runtime.

Jeremy.

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