[jcifs] Network name no longer available

Jake Goulding goulding at vivisimo.com
Mon Nov 26 22:24:03 GMT 2007


Thanks for the clarification about the error message. However, I'm not
sure the DFS vs BFS approach will help.

In our application, we use jCIFS to basically list a directory, then
pass the path outside of Java. The path will eventually come back to
Java, but the actual lifetime of any one SmbFile is comparatively short
- either the time to list a directory or download a file. We also use
BFS in the section outside of Java.

Doing some more digging, we found this post to the mailing list from
quite a while ago, which seemed very similar:


We attempted to perform a similar task here. Our setup was a Windows
2003 server that had the Z drive shared as "test". This drive contains
quite a few VMWare disk files that are 2 GB each. We used 5 concurrent
threads to download these in parallel.

While downloading these files, we removed the share, let the server sit
for a bit, then recreated the share.

The five files we were downloading all had errors after a bit. This is
expected. However, the transfers after these 5 were also affected. We
would continue to get the following exception:

Caused by: jcifs.smb.SmbException:
Transport1 timedout waiting for response to SmbComReadAndX
[command=SMB_COM_READ_ANDX, received=false, errorCode=0, flags=0x0018,
flags2=0xC003, signSeq=0, tid=2052, pid=19653, uid=6144, mid=8779,
wordCount=12, byteCount=0, andxCommand=0xFF, andxOffset=0, fid=16386,
offset=0, maxCount=16574, minCount=16574, openTimeout=-1, remaining=0,
 at jcifs.util.transport.Transport.sendrecv(Transport.java:76)
 at jcifs.smb.SmbTransport.send(SmbTransport.java:606)
 at jcifs.smb.SmbSession.send(SmbSession.java:239)
 at jcifs.smb.SmbTree.send(SmbTree.java:109)
 at jcifs.smb.SmbFile.send(SmbFile.java:695)
 at jcifs.smb.SmbFileInputStream.readDirect(SmbFileInputStream.java:160)
 at jcifs.smb.SmbFileInputStream.read(SmbFileInputStream.java:121)
 at jcifs.smb.SmbFileInputStream.read(SmbFileInputStream.java:111)

Looking at the server over Remote Desktop, we noticed that only one file
was ever open at any given time, whereas 5 were concurrently open
before. Killing Java and starting fresh, this behavior went away, and
all 5 files were open concurrently.

Please let me know if I can provide any more information or run more tests.



Michael B Allen wrote:
> On Fri, 16 Nov 2007 10:58:25 -0500
> Jake Goulding <goulding at vivisimo.com> wrote:
>> All:
>> Every so often, on a long crawl, we will get intermittent errors that say:
>> The specified network name is no longer available
>> I assume that this is being passed directly from the system, and that it
>> means what it says, but I wanted to check with the list to see if
>> there were any other meanings associated with it.
> Hi Jake,
> Yes, that error is coming directly from the server. JCIFS only emits one
> NT status code artificially which is NT_STATUS_ACCESS_VIOLATION when it
> detects that the credentials being used were supplied by the NTLM HTTP
> Filter (which is not applicible to you).
> Chances are, you collected info on the share in an eariler pass and it
> has since become inaccessible for some reason (e.g. someone unshared it).
> To minimize these sorts of scenarios it can help to do Breadth First
> Search (as opposed to Depth First Search) and use a working set that
> is as small as possible (e.g. no larger than the contents of any one
> directory per thread).
> Mike

More information about the jcifs mailing list