[jcifs] Re: SmbException in jcifs-1.2.7

Rainer Buss rainer.buss at rbconsult.de
Thu Jan 5 10:04:14 GMT 2006

Michael B Allen <mba2000 <at> ioplex.com> writes:

> On Wed, 4 Jan 2006 13:47:26 +0000 (UTC)
> Rainer Buss <rainer.buss <at> rbconsult.de> wrote:
> > Hi,
> > 
> > I am a new user of jcifs.
> > We are using jcifs-1.2.7 in an application that scans an remote directory
> > in 20 sec interval for new files. We often get exceptions like these shown
> > below and are not shure, if these messages indicate severe errors corrupting
> > further connections or errors as described in release text for jcifs-1.2.4:
> > 
> > "It was discovered that the new transport (as of 1.2.x) could not cleanly 
> > recover from temporary server failure (e.g. a restart). This has been 
> > Methods will still throw Exceptions but the moment the server comes back 
> > the client should gracefully recover."
> So is the machine offline when this happends? And jCIFS never recovers?
> > The errorCode is always 0 or 'The operation completed successfully' ?!
> It is VERY strange that the debug output would print 0 or 'The operation
> completed successfully'. 1.2.7 prints 0 for errorCode ALWAYS. Could it be
> that you have some old jar files hidding in your classpath somewhere? Try
> moving the 1.2.7 jar file out of the CLASSPATH temporarily and see if
> the app still runs.
> > Is it possible to avoid these errors by setting properties as
> > jcifs.netbios.retryCount ?
> No, that property if for name service lookups. See the overview page of
> the API documentation for meaningful properties.
> Mike

Hi Mike,

you are right. A closer look upon the log- messages shows, that 
error messages with 'The operation completed successfully' have been
written until we changed from jcifs-1.2.3 to jcifs-1.2.7.
Last night we had only error messages with errorCode=0.

The machine serving the remote directories, we are accessing, is
always up, but sometimes there seem to be network problems
or there may be problems with concurrent accesses ?

Our application is a transfer demon, that copies remote files 
to a local directory with some transformation. We have several 
file types and for each file type a demon thread is started.
So it may be that two threads try to access the same remote
directory at the same time. These threads are not synchronized via
semaphore, because the application was build for a separate mount demon,
we used before jcifs. 

Yesterday we had occasional error messages until in the evening
all threads throw these exceptions for about 20 minutes. Afterwards there
have been no exceptions any more (we think that our application did run),
but new files have not been recognized. (We had to restart the application)

When a thread scans a directory a new directory object is instantiated like:

try {
SmbFile directory = new SmbFile(source);
String[] files = directory.list();
... do something
} catch(Exception ex) {

Could you please answer the following questions:

Is each instantiation of SmbFile a new (system-) mount in  jcifs ?
Is this (system-)mount closed after life cycle of SmbFile instance ?
Is the number of parallel mounts on the same remote directory a problem ?
When we create a global SmbFile - instance for a directory, is
directory.list() actual for each access or is there a delay.



> > Error transferring File : jcifs.smb.SmbException: 
> > jcifs.util.transport.TransportException: Transport1
> > timedout waiting for response to Trans2QueryPathInformation
> > 

More information about the jcifs mailing list