Re: leading space char in smb file name

Thanks Jim,

You were already on the TODO but I updated to note your new post.

Note that the patch from [email protected] on Aug 15, 2011
might be more interesting at first glance. I just put it in the
patches directory. It's called url_leading_space.patch. Not sure if it
properly handles the # symbols though.

Whatever the case, this is already on the TODO list twice.

Mike

On Mon, Apr 16, 2012 at 7:48 AM, Jim Hurne <[email protected]> wrote:
> 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
> [email protected] | 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
>> <[email protected]>  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
>>
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/