[jcifs] skip(long) implementation in SmbFileInputStream

[Michael B. Allen]

On Sat, 14 Sep 2002 21:52:28 +0200
"Bas Leijdekkers" <basleijdekkers at hotmail.com> wrote:

> On Saturday, September 14, 2002 9:05 PM, Michael B. Allen wrote:
> > On Sat, 14 Sep 2002 20:53:19 +0200
> > "Bas Leijdekkers" <basleijdekkers at hotmail.com> wrote:
> >> I think it would be nice if the method skip(long) was implemented in
> >> jcifs.smb.SmbFileInputStream. The default implementation of
> >> java.io.InputStream just calls read(byte[], int, int) and throws
> >> away the results. A bit of time and bandwidth can be saved by
> >> implementing a more efficient version. My suggestion:
> >>
> >> public long skip(long n) throws IOException {
> >>   n = Math.min(file.length() - fp, n);
> >>   fp += n;
> >>   return n;
> >> }
> >
> > I'm not sure you can do this without an SMB_COM_SEEK. Have tested this
> > on a few different servers and are you sure you getting the right
> > thing?
> 
> I don't know what a SMB_COM_SEEK is, or why I would need it. I just looked
> at the SmbFileInputStream code and noticed skip(long) was not implemented. I
> wanted to built a sort of download manager for SMB, and needed something to
> resume a download when it was interrupted. After looking at
> SmbFileInputStream for a bit, I implemented the method above.
> I tried it with some (zip)files on a windows 98 share. The files were
> transferred just fine when the download was stopped at 64KB and then resumed
> with a skip(65536). I will test some more with other machines.

Actually I remember now someone did this and they said it worked fine. I
simply forgot about it. Please test a few other machines. I'll apply
your patch regardless.

> 
> Bas
> 


-- 
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 importantly to tasks that have not
yet been conceived.