JCIFS: file retrieval is too slow to be usable

What I noticed is that jCIFS does "something" (afair jcifs.smb.SmbTransport.checkStatus(..)) for every chunk it reads - i.e. for each chunk that is read into the buffer. That means using a BufferedInputStream might really speed things up, but the real problem still exists. It only doesn't occur as often as before and therefore has a lower impact on the overall time ..

It helps a lot to set "jcifs.util.loglevel=3" and have a look what's really wrong!

In my case I had to set "jcifs.smb.client.dfs.disabled=false" in the end, as "jcifs.resolveOrder=DNS" didn't help..

In my own case, pushing files TO a Windows share via JCIFS was too slow to be usable.

The solution turned out to be defining the property

-Djcifs.resolveOrder=DNS

The default inclusion of BCAST -- broadcasting a NetBIOS name query to 255.255.255.255 -- was needlessly resulting in a lengthy delay. (Link above de-framed from the top-level API docs.)

I found somewhere that SmbFileInputStream doesn't do its own buffering and hence the reason for being slow. Wrapping SmbFileInputStream in a BufferedInputStream solved the problem.

 SmbFile sFile = new SmbFile(path, authentication);

 BufferedInputStream buf = new BufferedInputStream(new SmbFileInputStream(sFile));

If you can rely on "something else" to mount the share as a local directory for you, then reading files in the mounted share in Java should be portable.

Even if this is not a real solution, it would be worth trying this to see if you get a faster read rate. A significantly faster read rate might change your mind about the relative importance of portability. And if you don't get a significant speedup, then you'll know that JCIFS is not to blame ...