[jcifs] Plusses, again.

[Rob Wygand]

Mike,

Been doodling with this. I tried wrapping all of the name params of the 
new SmbFile() calls in all the listFiles() methods of SmbFile in 
URLEncoder.encode calls(). This properly returns the path everytime 
fully encoded. That *really* sucks for display purposes, though, because 
now every path is always encoded and needs to be decoded for display. 
Usually, though, we're only displaying the last bit, so maybe that's not 
as bad a soultion as I think.

What might be better, though, would be to keep the *internal* stuff 
always encoded, so it works... but to either add a new getDecodedPath() 
or just always return the path in decoded format. If you do that latter, 
then you always need to re-encode, which is expensive.

What're your thoughts on the matter?
rjw

Rob Wygand wrote:

> Mike,
> 
> I found a bona fide bug regarding encoding, this time. =)
> 
> Here's the skinny: I have a directory named 123+ with a subdirectory of 
> HR+Recruiting. Here's my sample code to list all the children of 123+
> 
>   SmbFile[] files = null;
> 
>   SmbFile a = new SmbFile ("smb://server/share//123%2B"); // 123+
>   System.out.println (a.getCanonicalPath());
>   files = a.listFiles();
>   for (int i = 0; i < files.length; ++i)
>   {
>     System.out.println ("\t" + files[i].getCanonicalPath());
>   }
> 
> Here's the output:
> 
>   smb://server/share/123%2B
>     smb://server/share/123%2B/HR+Recruiting
> 
> Note that the + in 123+ is encoded, as I passed it in, but the + in 
> HR+Recruiting is not encoded. This is very bad. If *none* of it is 
> encoded, I can always encode it. if it's always encoded, I can always 
> decode it, but if parts of it are decoded and parts of it are not, I 
> don't know what I should do with each part. Is that %2B an encoded 
> value, or is it the literal name of the directory??
> 
> 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/e410ab54/smime.bin