Character set and client code page in samba 2.0.6.
jeremy at valinux.com
Tue Jan 4 03:32:20 GMT 2000
> But what will happen if
> we try to use smbclient to access Windows PC's share with
> CP852 characters in its name?
This is an interesing question. Does this work when accessing a Samba
share containing the same CP852 characters ?
> We can invoke smbclient with
> share's name written with ISO8859-2 characters and get
> connection. In our command all ISO characters are properly
> mapped to CP852 ones. But if we now execute dir command, the
> result will be completly unreadable. All filenames with CP852
> characters will be distorted - some of them will vanish,
> others will be mapped unproperly. To examine the problem more
> closely, one can use below command to save share's listing in
> a file:
> ./smbclient //PCNAME/ISO8859-2_share -c dir > PC.dir
> After opening PC.dir in vi editor we will see that characters
> (for example) 0x88 and 0xa5 from CP852, are mapped to ^Z and
> character 0x98 is mapped to 0xc2. One could expect that 0x88
> is mapped to 0xb3, 0xa5 to 0xb1 and 0x98 to 0xb6 which are
> ISO8859-2 equivalents of CP852 characters. Of course, ^Z
> mapped characters are not visible on terminal screen.
> It is also impossible to get correct result from this
> ./smbclient //PCNAME/share -c "cd ISO8859-2_dirname;dir"
> Where ISO8859-2_dirname is the equivalent of CP852 dirname
> existing on a PC. We will get such an error:
> cd ISO8859-2_dirname: ERRDOS - ERRbadpath (directory invalid)
> To obtain desirable result, we are forced to use such a
> trick: we write share's name using ISO8859-2 equivalents of
> CP852 characters and CP852 characters of PC dirname. A little
> intricate, isn't it? At this moment I gave up and removed
> character set = ISO8859-2 and client code page = CP852 lines
> from smb.conf, but it occured that PC Windows clients are not
> able to copy their files to server if filenames contain CP852
> None of previous 2.x samba versions behaved in this way (I've
> stopped using it because of the incredible low speed of put
> and get commands). I was able to manipulate the content of
> PC's share using ISO8859-2 characters in place of CP852 ones
> (although dir command always returned listing with CP852
What changed for 2.0.6 is that smbclient now assumes that
the filenames being returned are in the codepage format
that is specified in "client code page =" in the smb.conf,
and will convert, using the dos_to_unix() function, to
the character set used by the UNIX box (as specified in
the "character set =" parameter).
Now, can you please test doing this against a share exported
from a Samba 2.0.6. server. If that works correctly (the
filenames are being seen ok), but doesn't work when the
ls is done against a Windows PC (and also the version of
Windows being used as a fileserver will be very usefull
here) then we need to look more carefully at the code page
of the filenames being returned by a Windows file server.
Thanks for your help on this, please get back to me asap
as we are trying to decide upon the fixes that should go into
Samba 2.0.7 at the moment.
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
More information about the samba-technical