[jcifs] Problems with SmbInputStream.skip() method...

Michael B.Allen mballen at erols.com
Sun Dec 16 08:10:12 EST 2001

On Sat, 15 Dec 2001 15:45:53 +0100
"Torgny Johansson" <torjo845 at student.liu.se> wrote:

> Hallo,
> I'm using the SmbInputStream to download files and I was trying to implement
> resuming of unfinished downloads. I did this by checking how large the local
> file was and then sending that to SmbInputStream.skip() method. However it
> seems that the skip() method takes very long time if you've already
> downloaded a large part of the remote file and have to skip many bytes
> before you should start reading.
> Since the skip() method is inherited from io.InputStream I suppose that this
> problem isn't in jcifs, so what would the right approach be to start reading
> from a specified offset from the remote file?

skip() won't work. It will still read the data but just discard that
many bytes. If you look at jcifs/smb/SmbFileInputStream.java's main read
method you'll see:

file.send( new SmbComReadAndX( file.fid, fp, r, null ), response );

So the SmbComReadAndX constructor specifies the parameters in the
SMB_COM_READ_ANDX message set to the server for each read operation. The
parameters are file id, *file pointer*, the max number of bytes to read,
and the AndXServerMessageBlock object if any. So fp is the current offset
within the file and is a member of the SmbFileInputStream object. IOW,
I think you could add a method to SmbFileInputStream like:

public void seek( int off ) {
	fp = off;

This is of course not a *real* seek so it's a little bit of a hack and
it might fail miserably but I think it will work. Someone also posted
a RandomAccessFile implementation that I can send you if you wish but
I've never tested it and it's certainly out of date at this point.


May The Source be with you.

More information about the jcifs mailing list