[jcifs] leading space char in smb file name
Michael B Allen
ioplex at gmail.com
Tue Apr 17 03:55:06 MDT 2012
You were already on the TODO but I updated to note your new post.
Note that the patch from sebastian.sickelmann at gmx.de 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.
On Mon, Apr 16, 2012 at 7:48 AM, Jim Hurne <hurne at vivisimo.com> 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.
> 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:
>>> 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
>>> new SmbFile("smb://server/share/folder/").listFiles.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.
Michael B Allen
Java Active Directory Integration
More information about the jCIFS