[jcifs] leading space char in smb file name

[Jim Hurne]

Hello Michael,

We ran into this problem as well. We also ran into similar problems with 
filenames starting with with ".#" and "..#".  To fix the problems, we 
ended up modifying the jcifs.smb.Handler class which is responsible for 
parsing smb URLs. Our changes are included in the attached patch.

The two issues are a direct result of the differences between HTTP URLs 
and "smb" URLs.  The jcifs.smb.Handler class extends the 
java.net.URLStreamHandler class.  The jcifs.smb.Handler class delegates 
a lot of processing to the URLStreamHandler class. however, the 
URLStreamHandler class parses URLs per the various HTTP specifications. 
which isn't always appropriate for SMB URLs.  Thus, the call to 
super.parseURL is wrapped in code which tries to modify the output to 
match what you would expect for SMB URLs.

To fix the leading whitespace issue, we updated the jcifs.smb.Handler 
class to check the original input (the spec variable) after the call to 
super.parseURL to see if it contained leading whitespace. If it does, 
then the leading whitespace is added back into the path component of the 
URL.

I know Mike is hesitant to apply the patch to the official JCIFS 
distribution because this is a rather sensitive part of the library 
(parsing URLs affects everything).  However, we've been using it in 
production for a few years in a variety of environments (large and 
small) without any problems.  I've also attached a JUnit 4 test class we 
used to test the modifications.  Nonetheless, the patch comes with no 
warranty and we cannot be held responsible if it doesn't work as 
expected or causes other problems.

Regards,

Jim Hurne | Software Engineer
Office: +1.412.422.2499
1710 Murray Avenue, Pittsburgh PA 15217 USA
hurne at vivisimo.com | Connect: www.vivisimo.com
Vivisimo - Information Optimized

On 04/13/2012 10:07 PM, Michael B Allen wrote:
> On Wed, Apr 11, 2012 at 5:21 PM, Anonymous
> <nobody at remailer.paranoici.org>  wrote:
>> Hi,
>> I had a problem with the SmbFile.
>> I had a file with name "smb://server/share/folder/ foo.bar" on a smb server  ( foo.bar with leading blank). This file was created with jcifs, but calling
>> new SmbFile("smb://server/share/folder/").listFiles[0].getName() only returns "foo.bar" with no leading blank.
>>
>> Before I had this problem, I didn't believe that it is possible to have files with leading blanks...
>>
>> I've analyzed the problem, and figured out, that everything is transfered correct from the server to jcifs.
>> In the internal variable unc the path is stored with blank, but in canon, what is used for get name it's not.
>>
>> I hope that helps improving jcifs
> Hi Michael,
>
> This is a known problem. It is the java.net.URL class that is doing
> it. When the listFiles routine calls the SmbFile constructor the name
> is passed to the URL class which is trimming the space. There are
> other characters that are known to cause problems like this such as #
> at the end of names. There's not much we can do about it other than to
> dump the java.net.URL class at some point but that would require a
> complete re-write.
>
> Note that if you use an SmbFilenameFilter you can get to the
> un-trimmed filename. But I don't know if that will help you because I
> don't know if you will be able to create an SmbFile instance with it.
>
> Mike
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: leading-space-or-dots.patch
Type: text/x-patch
Size: 2618 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20120416/ae6cd559/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmbUrlTest.java
Type: text/x-java
Size: 9013 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20120416/ae6cd559/attachment.java>