File corruption again

[Juergen Hasch]

Jeremy Allison schrieb:
> 
> On Sat, May 26, 2001 at 07:05:30PM +0200, Juergen Hasch wrote:
> >
> > Finally I found a way to trigger my problem independent of the log
> > level.
> > I think I spotted the place, where the file corruption comes from.
> > It's in reply.c/reply_write_and_X()
> >
> > I am copying a 8628 bytes file to the Samba share:
> > smb_doff= 63, smblen=8691, numtowrite=401844
> > This triggers the ERRbadmem error and the created file is empty.
> >
> > Copying it a second time yields:
> > smb_doff= 63, smblen=8691, numtowrite=8628
> > No error and the created file is valid.
> 
> Well spotted. I'm back from Japan and trying to catch
> up. Can you send me a debug level 10 for this one (or
> a .cap file). It looks like in some cases the vwv10
> field is non zero.
Welcome back :-)

> 
> I need to understand when it's safe to look at the
> vwv10 field and when it's not....
> 
I have been testing this with NT4 server + workstation with SP6a as well
as Win2K pro. The tests were performed with Samba running under 
Linux/Solaris/Aix, the results remain the same.

With NT4 the vwv9 field has "strange" values. It's mostly set to 6,
but can get almost any onther value. Usually these values are small
and below 0x20.
I could not find any pattern, the values aren't size related.
Win2K works OK, vwv9 is alway 0 or 1. 

But wait - it's getting even stranger. Turning oplocks off I get
no corruption under NT4 any more.

Also, when running Samba under Linux and creating a share
on a tmpfs (shm) filesystem, I can only copy files up to 65535 bytes
to the share using Win2K. Larger files fail.
Removing CAP_LARGE_ from negprot.c let's me copy any file to the tmpfs
share.
I looked at the logs, but I didn't see any obvious error message. It's
looks like it's not vwv9 related.

...Juergen