[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