[jcifs] Plusses, again.

Michael B Allen mballen at erols.com
Thu Jan 24 07:39:03 EST 2002


On Wed, 23 Jan 2002 11:11:00 -0800
Rob Wygand <rob at wygand.com> wrote:

> I've done some additional testing... if I pre-encode the URL (that is, I 
> use a StringTokenizer to get e each part of the path and then call 
> URLEncoder.encode() on each part,then reassemble the path) to:
> 
> SmbFile x = new SmbFile ("smb://server/share/dir%2Bname");
> 
> I can call listFiles() and everything works!

I don't understand Rob. This is how it's supposed to work. If you do:

> >   SmbFile x = new SmbFile ("smb://server/share/1+2").mkdir();

it will and should create a directory called '1 2' with a space because
'+' is the proper URL encoding for space.

> > however, x.getCanonicalPath() properly shows "smb://server/share/1+2".

It's encoded though. This is what has changed from previous betas and
it's absolutly correct. These get methods that return part or all of
the URL will return /what you put in/. You we the one that identified
the issue where an SmbFile derived from an SmbFile created with a URL
with encoded characters in it was throwing MalformedURLExceptions. This
is because we used to removed the encoding in the constructor passing
a bad URL to the childs constructor. Now you get out what you put in so
the encoding is preserved when creating new derived SmbFiles.

> > They also being mishandled in list... that is, if I try the following:
> > 
> >   SmbFile x = new SmbFile ("smb://server/share/dir+name");
> >   SmbFile[] = x.listFiles()

This encoded URL will list files in the 'dir name' directory.

> > 
> > I get a File does not exist operation...

Right.

> > This was working in previous betas, so something has changed recently 
> > causing this to break again... I know that you changed the 
> > encoding/decoding process somewhat. Thoughts?

No, it was broken in previous betas and we fixed it. You were the one
that found the bug! :~P

Mike

-- 
May The Source be with you.




More information about the jcifs mailing list