I am going to place this patch in a patches directory. I have removed
the Encdec change however. I believe the correct fix for that issue is
the following in doRecv:
int size = Encdec.dec_uint16be( BUF, 2 ) & 0xFFFF;
It's correct for dec_uint16be to return a short. We just need to ensure
that the value bahaves as if it were unsigned which is a simple matter
of masking out the lower 16 bits.
On Wed, 19 Oct 2005 17:03:34 +0200
Thomas Krammer <[hidden email]> wrote:
> the attached patch adds LARGE_READX / LARGE_WRITEX support to jCIFS
> 1.2.6. It also fixes some problems I found along the way.
> 1) Debug output in Transport.java
> The patch removes some debug output that is printed to stdout.
> 2) Integer overflow in SmbTransport.java
> If you execute the following code:
> SmbFile serverFile = ....
> SmbRandomAccessFile ra = new SmbRandomAccessFile(serverFile, "rw");
> int BUFFER_SIZE = Short.MAX_VALUE;
> byte buffer = new byte[BUFFER_SIZE];
> you will get the following exception:
> jcifs.util.transport.TransportException: Transport1 timedout waiting for
> response to
> at jcifs.util.transport.Transport.sendrecv(Transport.java:74)
> at jcifs.smb.SmbTransport.send(SmbTransport.java:580)
> at jcifs.smb.SmbSession.send(SmbSession.java:229)
> at jcifs.smb.SmbTree.send(SmbTree.java:102)
> at jcifs.smb.SmbFile.send(SmbFile.java:688)
> at jcifs.smb.SmbRandomAccessFile.read(SmbRandomAccessFile.java:86)
> at jcifs.smb.SmbRandomAccessFile.read(SmbRandomAccessFile.java:69)
> The reason for this error is an integer overflow in
> SmbTransport.doRecv() line 422. If the specified buffer size is greater
> than Short.MAX_VALUE - SMB_HEADER_LENGTH the package size gets negative
> and the package is rejected. That's because Encdec.dec_uint16be returns
> a short instead of an int.
> Please note that there are more similar errors in Encdec (for example
> dec_uint32be returns an int instead of a long). I didn't fix those
> additional errors.
> 3) LARGE_READX and LARGE_WRITEX support
> The patch adds LARGE_READX and LARGE_WRITEX support for
> SmbFileInputStream, SmbFileOutputStream and SmbRandomAccessFile. This
> significantly increases the performance when transferring files from and
> to Windows servers.
> For example transferring a 183 MB file (using streams):
> modified 1.2.6 original 1.2.6
> Download 23 sec 39 sec
> Upload 26 sec 40 sec
> Client: Windows XP SP 2, Java 1.4.2_08
> Server: Windows XP SP 2
> The test used a 128k buffer to transfer the data from the InputStream to
> the OutputStream.