[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.

Mike

-- 
May The Source be with you.




More information about the jcifs mailing list