File copy bug in HEAD branch

[Tim Potter]

As a lead up to my VFS merge, I've done a spot of testing on the HEAD
branch and there seems to be a problem with data corruption.  To
produce the problem, I created a 1MB file (I created a file with
repeating 0x00-0xff sequences) and copied it using the HEAD branch
samba.  Diff the copy of the 1MB file and the original and it turns
out they are not the same!  At offset 2d000 to offset 47fff, the
sequence

002d000 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf

becomes

002d000 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0

and continues for approximately 108K when it magically gets back into
sync (actually not quite - it jumps from c0 at offset 47fff to 00 at
offset 48000).

I've traced the calls through reply_read_and_X() and the data is being
read from the local file correctly.  It then disappears into (from
reply.c)

  SSVAL(outbuf,smb_vwv5,nread);
  SSVAL(outbuf,smb_vwv6,smb_offset(data,outbuf));
  SSVAL(smb_buf(outbuf),-2,nread);

then

  return chain_reply(inbuf,outbuf,length,bufsize);

Anyone have any clues?  I've tested it with 1.9.17p1 (works) and the
HEAD branch (doesn't work) and [quickly compiles up SAMBA_2_0 version]
well what do you know it works in the 2.0 branch. Is this a patch that
hasn't been merged yet?  I'm using a NT4 SP4 machine to do the testing
on.

I don't want to be blamed for causing this bug.  (-:


Tim.

-- 
Tim Potter, System Admin/Programmer, Head Bee Guy
Advanced Computational Systems CRC, RSISE Bldg Australian National University,
Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602