[jcifs] Name caching issue

Michael B Allen ioplex at gmail.com
Wed Mar 11 23:01:00 GMT 2009

On Wed, Mar 11, 2009 at 5:46 PM, Tony Thompson
<Tony.Thompson at stone-ware.com> wrote:
> I am having a weird name caching issue that I can't figure out how to
> resolve.  I am using jcifs 1.2.19 but I have also tried 1.3.4 and still
> see the same issue.  I am using jcifs in a java application that I start
> once and then leave the JVM running through this whole test (restarting
> the JVM fixes the issue which is why I think it is a caching thing).  I
> am simply doing this to test the connection:
> NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(
> domain, userName, password );
> SmbFile file = new SmbFile( "smb://$", auth );

If  you use an IP, JCIFS will do a "node status" to try and figure out
the name of the machine.

> The machine that I am connecting to is a Windows machine.  The first
> time I connect, everything is fine.  If I rename the windows machine and
> reboot it, the next time I try the above code, I get an SmbException
> with NT_STATUS_INVALID_PARAMETER = 0xC000000d.  A packet trace indicates
> that the user ID is invalid (it is not since it worked the first time)
> and a renegotiation doesn't happen, just the exception is thrown.

This doesn't shock me. It's just not a scenario that I have tested.

It sounds like the cached SmbTransport is hanging onto the name. If
the transport is disconnected, it should destroy that information. Or
maybe the name is being cached elsewhere. In fact, if it's the NetBIOS
name service cache it should timeout after a while. How long did you
wait after renaming the machine?

My guess is this is just a bug in the SmbTransport class. When it's
disconnected it should reset the name.

> Third and subsequent attempts attempts throw an SmbException with
> NT_STATUS_DUPLICATE_NAME = 0xC00000bd.  A packet trace indicates that
> the authentication negotiation completed fine this time but the path in
> the "Tree Connect" request is using the old machine name.  So, the path
> is something like "\\TEST\C$" instead of using the new machine name
> "\\TEST2\C$".

Ok, so maybe the SmbTree class is caching the name and it needs to
properly destroy the name when it get's disconnected.

I've added this to the TODO list but this is definitely a "Free time"
issue. The "Free time" issues are usually handled about once a year or
so and usually also require that they be precipitated by other work
paid for by a sponsor (I don't charge the sponsor for the unrelated
issues but they get folded in as long as I'm doing the work).

Translated: Don't wait for me to fix this.


Michael B Allen
Java Active Directory Integration

More information about the jcifs mailing list