[jcifs] RE: jCIFS corrupt files
barry.roberts at xactsites.com
barry.roberts at xactsites.com
Thu Oct 2 13:07:17 EST 2003
The reason I haven't suspected the servers (Samba 2.2.3a-12.3 and 2.0beta2 on Debian, 2.2.7-1.7.3 on RH 7.3) is because they haven't been re-started for months. I have multiple app servers and only one at a time starts getting errors, and re-starting the app server fixes the problem. Other app servers just keep working along without errors simultaneously.
But if jCIFS keeps a connection open to the samba server and something on the server side related to that connection is getting corrupted, that would explain the behavior. Does jCIFS do that? I looked for properties relating to that kind of thing, but all I found was for the naming connection, and AFAIK, that's different. If jCIFS does keep the connection to the server open are there api calls to force it to close and re-connect? That would be something to try and faster than shutting down the app server and re-starting it. Or properties to set would be fun to try, too.
From: Michael B Allen [mailto:mba2000 at ioplex.com]
Sent: Wed 10/1/2003 5:44 PM
To: Barry Roberts; crh at ubiqx.mn.org
Cc: jcifs at samba.org
Subject: RE: [jcifs] RE: jCIFS corrupt files
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.
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the jcifs