[jcifs] Re: Failed to access files on Samba server with path in Chinese

Michael B Allen mba2000 at ioplex.com
Mon Dec 20 19:42:11 GMT 2004

On Mon, 20 Dec 2004 09:46:48 +0000 (UTC)
joller <joller at intumit.com> wrote:

> > The Samba server is probably configured to use an 8 bit encoding as
> > opposed to Unicode. By default jCIFS will use the 'file.encoding' System
> > property to decode filenames. Therefore jCIFS will only behave properly
> > with default settings if both the Samba server codepage and the Java VM
> > file.encoding are compatible. If they are not compatible, you can
> > override the encoding using the 'jcifs.encoding' property. Such as:
> > 
> >   jcifs.encoding=Big5
> Hi Mike, 

Hi joller,

What versions of Samba and JCIFS are you using?

>   In fact we have tried to set the property `jcifs.encoding', 
>   and the result is as follows:
>   With this property set to `big5', SmbFile.exists() returns true, 
>   while SmbFile.getInputStream() fails with the same exception
>   as mentioned;

Ok, so the file.encoding is probably already set to Big5.

>   With `utf8', SmbFile.exists() returns *false*, 
>   and SmbFile.getInputStream() fails with the same exception. 
>   It seems that big5 is the correct encoding. 
>   Besides, I wonder why there is no such problem when the client 
>   is a Windows file manager.

If the Java VM was not cofigured correctely you would need to set the
ecoding. But it seems it is probably correct.

>   If the server is not a Samba, but is a Windows PC instead, 
>   there is no such problem either.
>   Does this mean that the way jcifs talks to the server is different from 
>   that of a Windows file manager?

Potentially yes. If Windows is negotiating Unicode and Samba is
negotiation 8bit-mode then the way strings are decoded and encoded is a
little different. We haven't had any reports of problems and I know we
have some CJK users but there certainly there could be a bug in 8-bit
mode communication. Or it's a bug in Samba.

>   And why SmbFile.exists() correctly returns true in this case?
>   SmbFile.lastModified() also returns the correct information.
>   It seems that querying information of a file works fine with Chinese
>   path.

It just means that there is a bug in the NT_CREATE_ANDX command in either
jCIFS or Samba. To determine which we need three packet captures [1];
one of jcifs failing against samba, one of Windows succeeding against
samba, and one of jcifs succeeding against windows.


[1] http://jcifs.samba.org/capture.html

Greedo shoots first? Not in my Star Wars.

More information about the jcifs mailing list