[jcifs] Plusses, again.

[Rob Wygand]

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/fe9b968c/smime.bin