[jcifs] Plusses, again.

[Rob Wygand]

Allen, Michael B (RSCH) wrote:

> 	Yikes! We're really going around in circles now aren't we?


Oh yes. =)

> 	Knowing that, there is no way to know if the user intended that a character be treated
> 	litterally or not. For example a '+' sign might be litterally a '+' or it may be a space. So
> 	we must unconditionally decode everything after the authentication information.


Right. I'm with ya.

> 	So, about this particular problem, it occurs because the list* functions are appending
> 	the file or directory name literrally. The question is, if these routines unconditionally
> 	URLencode the child pathname will this lead to further issue? I think it will work.


I think your assumption is right. I've coded it and attached the diff 
that is currently working for me. Now everything is always encoded. This 
now actually saves me the trouble of have to pre-encode as listFiles() 
always returns encoded URLS. This makes me EXTREMELY happy, and in my 
mind, proves that it's the (a) right solution.

Here's the diff:


diff -r1.2 SmbFile.java
1135c1135
< 	 
							response.results[i].name,
---
 > 		 
						java.net.URLEncoder.encode (response.results[i].name),
1155c1155
< 	 
							response.results[i].netName,
---
 > 		 
						java.net.URLEncoder.encode (response.results[i].netName),
1198c1198
< 	 
						filename,
---
 > 		 
					java.net.URLEncoder.encode (filename),


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