[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jcifs
Subject:    Re: [jcifs] JCIFS and Share name with German character
From:       Peter Zavadsky <peter_zavadsky () symantec ! com>
Date:       2009-12-03 0:52:31
Message-ID: loom.20091203T015000-747 () post ! gmane ! org
[Download RAW message or body]

Michael B Allen <ioplex <at> gmail.com> writes:

> 
> That should work provided that the actual string supplied to the
> SmbFile constructor is in the right encoding. For example, if your on
> UNIX and your editor is running in a latin1 mode but javac is
> expecting a UTF-8 string literal, the ß might look right in the code
> but at runtime it would be in the wrong encoding.
> 
> Or the problem could be on the server if it were like an old NetApp
> server running in a latin1 locale.
> 
> If you send me a packet capture I could at least tell you from which
> end the problem is originating.
> 
> Or it could be a bug in JCIFS. I vaguely recall something like this
> where Unicode values like this needed to be URL encoded but JCIFS
> didn't properly decode them internally and some extra funky step was
> required.
> 
> Mike
> 

The encoding shouldn't be the issue (It is same when I have UTF-8 
and use \u00DF to represent ß). 
Anyway we succeeded to narrow the problem.

Now we have at hostname following two shares:
Shareß
ShareSS

Then following code:
new SmbFile("smb://hostname/Share\u00DF").exists();

will work, but only because the SmbFile instance actually represents
ShareSS and not the expected Shareß (we verified that by checking
the content of the retrieved share).

As mentioned there is a bug in Java, which uppercases ß character into SS
string. Therefore I assume that inside the JCIFS code is done uppercase
of the URL, which leads to this problem.

Thanks,
-Peter


[prev in list] [next in list] [prev in thread] [next in thread]