[jcifs] RE: jCIFS corrupt files

[barry.roberts at xactsites.com]

Last night I recompiled my own version of jcifs with SmbFileOutputStream.write and SmbFileInputStream.read() synchronized.  I have not been able to reproduce any corrupt files.

So it doesn't require multiple threads once the JVM/jCIFS whatever has gotten into a bad state, but it is much easier to get into that state with multiple threads. I was running a 20-thread stress test to reproduce it.  Each thread should have been writing to it's own files, but they all do a fair amount of SmbFile*putStream IO in close time proximity.

Thanks for the help.  I really like jCIFS.

Barry Roberts


-----Original Message-----
From:	Christopher R. Hertel [mailto:crh at ubiqx.mn.org]
Sent:	Wed 10/1/2003 12:29 AM
To:	Allen, Michael B (RSCH)
Cc:	Barry Roberts; jcifs at samba.org
Subject:	Re: [jcifs] RE: jCIFS corrupt files

On Tue, Sep 30, 2003 at 09:19:10PM -0400, Allen, Michael B (RSCH) wrote:
> I will need some time to look at this more closely. There are many offsets
> and lengths and things that I can look at in the capture. Just from a
> preliminary examination it does look like some numbers don't quote add
> up which could lead to what looks like 66 bytes being lost at the end of
> the first write (at least).

Yes, that was the first thing I noticed as well.  It appears as though 66
bytes is being lost from the offset after every Write&X.

Well, hang on...

 bytes   offset(calc)   offset(real)   error
  4930              0              0       0
  4930           4930           4864      66
  4930           9860           9728     132  (66 x 2)
  4930          14790          14592     198  (66 x 3)
  4930          19720          19712       8
  4930          24650          24576      74  (66 + 8)
  4930          29580          29440     140 ((66 x 2) + 8)
  4930          34510          34304     206 ((66 x 3) + 8)

If the file were just a bit bigger, the next entry would be interesting.

Note above when things drop to an offset error of 8 bytes.  66 x 4 would
be 264, which is 8 more than 256.  That suggests that whatever counter is
messed up, it is a one-byte field.  When it exceeds 255 it simply wraps,
so the sequence would be:

error   & 0xFF
    0        0
   66       66
  132      132
  198      198
  264        8
  330       74
  396      140
  462      206
  528       16
  594       82
  660      148
  726      214

Somewhere there is a one byte value being incremented by 66 with the 
resulting value *subtracted* from the correct file offset.

I'm not sure where the 66 is coming from.  The NBT Session Service header
gives the message size as 4993, which is *63* bytes more than the data
transfer amount.  63?  Where are the other 3 bytes coming from?!  (The
data offset field agrees with the 63 byte value, as I *think* it should.)

That 63 bytes may, or may not, be related to the 66 bytes being fiddled.  
It's just a guess.

Again... which version of jCIFS!?

> I know Chris would be great at confirming my suspicions (nudge, nudge)
> 
>  <<badxmlwritecap.zip>>  <<badxml.zip>> 
> Right now I have something non-jCIFS related to take care of.

I'll bet that cat is much happier by now.  Cleaning out the waffle iron is 
going to be a pain, though.  I would simply replace the tuba.

[|-|P\:5 -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


-------------- next part --------------
HTML attachment scrubbed and removed