[jcifs] RE: jCIFS corrupt files
Michael B Allen
mba2000 at ioplex.com
Thu Oct 2 09:44:32 EST 2003
From: Christopher R. Hertel [ <mailto:crh at ubiqx.mn.org>]
> 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)
>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.
But all of the offsets and lengths are correct *and* the payload has the
data. So I don't think this is a jCIFS encoding problem. I don't see how
it can be. Nbt says 4993 - 63 = 4930 = smb.data_length = (0x5EA - 0x85) +
(0x5EA - 0x42) + (0x5EA - 0x42) + (0x2CF - 0x42). Everything adds up.
It sounds like it could be a server error. What types of servers have you
tried that generate corruption Barry?
Or, here's a way to get 66 though:
0x5EA - 0x42 (size of an NBSS Continuation Message from one of the
SMB_COM_WRITE_ANDX messages) = 1514
1514 + 32 for TCP header + 20 for IP header = 1566
but IP header Total Length field claims the entire message is on 1500. Oops!
1566 - 1500 = 66.
This 66 error would occur with each of the 4 messages per SMB though so
this might be a poor conclusion.
Can a network engineer out there confirm that an IP header 'Total Length'
should require that the actual payload be that size or can it go over?
This could be a framing error.
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
More information about the jcifs