[jcifs] SmbFile.listFiles() on own server takes a long time

Kid Kalanon kid_kalanon at hotmail.com
Fri Sep 27 11:41:51 EST 2002


Hi,

I'm experiencing a problem when trying to recursively list SmbFiles from 
root (smb://).  I've found that it takes a long time when trying to list 
shares from the local server.

Here's a bit of code to demonstrate this:
----------------------------------------------------

public class ListAll
{
  public static void main(String[] argv) throws Exception
  {
    SmbFile workgroup = new SmbFile("smb://workgroup");
    SmbFile[] servers = workgroup.listFiles();
    for (int i = 0; i < servers.length; i++) {
      long startTime = System.currentTimeMillis();
      try {
        servers[i].listFiles();
      }
      catch (Exception ex) { }
      System.out.println(servers[i] + " listFiles() took " +
            (System.currentTimeMillis() - startTime) + " milliseconds");
    }
  }
}

----------------------------------------------------

the output looks like (the actual names have been removed to protect the 
innocent):

smb://host1 listFiles() took 0 milliseconds
smb://host2 listFiles() took 47 milliseconds
smb://host3 listFiles() took 0 milliseconds
smb://host4 listFiles() took 6000 milliseconds
smb://host5 listFiles() took 0 milliseconds
smb://host6 listFiles() took 15 milliseconds

I am on a LAN with usually 5 to 6 computers running either Windows 2000 or 
Windows NT and all on the same workgroup.  There are no Linux or Unix boxes 
on the LAN.  As you can see, host4 is the culprit and that's the computer I 
just run the above code on.

I was wondering if anyone is experiencing a similar problem and more 
importantly, does anyone know how to fix it?



That's the gist of the problem, here's a bit more detail if you're keen to 
read on....

I've traced the problem down to NbtAddress class in method doNameQuery, 
here's a stack trace (I'm using jcifs_0.7.0b3):

jcifs.netbios.NbtAddress.doNameQuery(NbtAddress.java:303)
jcifs.netbios.NbtAddress.getByName(NbtAddress.java:431)
jcifs.UniAddress.getByName(UniAddress.java:260)
jcifs.UniAddress.getByName(UniAddress.java:186)
jcifs.smb.SmbFile.getAddress(SmbFile.java:723)
jcifs.smb.SmbFile.setTree(SmbFile.java:493)
jcifs.smb.SmbFile.sendTransaction(SmbFile.java:503)
jcifs.smb.SmbFile.listFiles(SmbFile.java:1233)
jcifs.smb.SmbFile.listFiles(SmbFile.java:1152)
com.arbiter.util.smb.ListAllServers.main(ListAllServers.java:110)

This function fails to find the NbtAdress (wrapper for ip address?) if the 
name is is the local computer's name.

I suspect this behaviour is platform dependent and network dependent.  We're 
not running any kind of "Name Server" or have configured anything special on 
the Windows boxes when we connected them together (eg. didn't modify the 
lmhosts.sam or hosts files) and this network is not expected to be 
accessible from the outside world.  The Windows File Explorer can browse 
networks fine and doesn't exhibit this problem ;)

The workaround for this problem I used was to add the following code to 
UniAddress.getByName before any lookup is done:

if (hostname.equalsIgnoreCase(
      InetAddress.getLocalHost().getHostName()) ) {
  return new UniAddress( InetAddress.getLocalHost() );
}

This, most likely is not the right way.  I don't understand the inner 
workings that well.  Can anyone suggest something better?


Kid.



_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




More information about the jcifs mailing list