[jcifs] getName weirdness...

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	rjw [SMTP:rob at wygand.com]
> Sent:	Monday, February 04, 2002 9:30 PM
> To:	Allen, Michael B (RSCH)
> Cc:	jcifs at samba.org
> Subject:	Re: [jcifs] getName weirdness...
> 
> Really? That's very odd... I'm using an unadulterated jCIFS dist. Hm. 
> Two things.. (1) I may only be seeing against Samba, and (2) here's my 
> test proggie:
> 
	Ok, now I see it. Itza bug. Shouldn't be too difficult to fix but I have to be very
	carefull in the URL code so gimmie a minute. The first case you mention is
	actually right though. If you input:

	smb://domain;user:pass@server

	getName will return

	domain;user:pass at server

	This is because it is a distinct component. The server name is not correct without
	the authentication information in this context. Do you not agree?

	Mike

> import jcifs.smb.*;
> 
> public class Test
> {
>    public static void main (String[] args)
>    {
>      SmbFile x = null;
>      try
>      {
>        x = new SmbFile ("smb://DOMAIN;rob:password@10.1.3.75");
> 
>        System.out.println ("server = " + x.getName());
>      }
>      catch (Exception e)
>      {
>        System.out.println ("Caught exception: " + e.toString());
>      }
>    }
> }
> 
> Allen, Michael B (RSCH) wrote:
> 
> >>-----Original Message-----
> >>From:	rjw [SMTP:rob at wygand.com]
> >>Sent:	Monday, February 04, 2002 6:23 PM
> >>To:	jcifs at samba.org
> >>Subject:	[jcifs] getName weirdness...
> >>
> >>Mike,
> >>
> >>If you attempt to list the shares on a server without a trailing slash 
> >>on the URL ("smb://10.1.3.1" vs. "smb://10.1.3.1/"), jCIFS returns 
> >>everything after the "smb://" as the name name of the requested file 
> >>when you call getName().
> >>
> >>
> > 	I don't understand. I'm not seeing this. The examples/ListFiles.java
> > 	program doesn't show this behavior anyway.
> > 
> > 
> >> If you use the trailing slash (which is 
> >>correct), jCIFS returns "smb://" when you call getName(). Really neither 
> >>of these behaviors are correct, IMO.
> >>
> >>
> > 	I'm not seeing this either.
> > 
> > 	Mike
> > 
>