[jcifs] Plusses, again.

[Rob Wygand]

Mike,

Oh, well, I guess I'm confused about what the fix should have been. =) 
What you say makes sense... I do remember identfying the bug, I just 
thought everything would still work magically on my end, I guess. I hate 
that I need to pre-encode the url ... that seems like extra work, only 
to have you decode it immedietly after I perform the encode.

Hm...
rjw

Michael B Allen wrote:
> 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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3229 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.samba.org/archive/jcifs/attachments/20020123/7717cd31/smime.bin