[jcifs] Oh, those wacky plusses.

[Allen, Michael B (RSCH)]

Ehh, that stinks. I think if we start encoding things so they are decoded properly later on we're
going to get caught in a looping mess. I think it would be better to just try and preserve the
encoding so that you (and SmbURL.parseSmbURL) get out what you put in. So if you do
"smb://server/share/file%2Bname" and print it you do NOT get the decoded ..hare/file+name"
version but rather the original string that you put in with the %2B in it. That's actually better
because the user can choose what they need to decode (which incedentally is just the '@'
sign I beleive; although the user might choose to URL encode other characters in the path).
The right way to do this I think, is to decode only the string used by actual server ops. This is
already setup I think because the SmbFile.uncPath is the only string used for server ops. The
stirngs url, canonicalPath, name, etc could preserve URL encoding.

Mike

> -----Original Message-----
> From:	Rob Wygand [SMTP:rob at wygand.com]
> Sent:	Thursday, January 03, 2002 6:38 PM
> To:	Allen, Michael B (RSCH)
> Cc:	'Rob Wygand'; jcifs at samba.org
> Subject:	Re: [jcifs] Oh, those wacky plusses.
> 
> URLDecode the canonical path before invoking SmbURL.parseSmbURL? That 
> doesn't seem right to me.... Rather, I think I'd need to URLEncode the 
> biths between the slashes so that when SmbUrl parses it, it would 
> properly decode from %xx notation into a +.
> 
> Am I missing something?
> rjw
> 
> Allen, Michael B (RSCH) wrote:
> 
> > I think this is simple enough to fix. We just need to URLdecode the canonical
> > path before running it through the SmbURL parsing routine.
> > 
> > Keep'em coming,
> > Mike
> > 
> > 
> >>-----Original Message-----
> >>From:	Rob Wygand [SMTP:rob at filefish.com]
> >>Sent:	Thursday, January 03, 2002 6:16 PM
> >>To:	jcifs at samba.org
> >>Subject:	[jcifs] Oh, those wacky plusses.
> >>
> >>Mike,
> >>
> >>Discovered an odd one. Generally, creating SmbFile's from a string that 
> >>contains plusses, works. For example, if I do:
> >>
> >>	x = new SmbFile ("smb://server/share/HR+Recruiting");
> >>
> >>I can do anything with that SmbFile... write to it's input stream, call 
> >>mkdir on it, whatever.  but if I do this:
> >>
> >>	x = new SmbFile ("smb://server/share/HR+Recruiting");
> >>	y = new smbFile (x, "foo");
> >>	y.mkdir();
> >>
> >>The last fails exceptionally, claiming that the path is invalid. When I 
> >>print out y.getCanonicalPath(), the + has been URLDecoded() away.
> >>
> >>This isn't be design is it? It works in one case and not the other...
> >>
> >>rjw
> >>
> > 
> 
>