Problem with Turkish character share names -- how to modify?

Deniz Akkus Kanca deniz at arayan.com
Tue May 22 12:06:33 GMT 2001


I realize re-reading my earlier message that it is quite confusing:

Ascii case transform:       i      -> I

Turkish dotted i transform:     i   -> \230
Turkish dotless i transform:     \215 -> I

So, when Samba receives request for HULUSI, it does the right thing by
looking for:
    HULUSI
    hulus\215

The sharename being  hulusi (and appearing that way for the Windows 857
client), the request for hulusi should have come as:
    hulusi
or HULUS\230

Ways of getting correct behaviour would be:

1. Getting windows to either preserve case during the sharename request, or
do the correct charmap (ask for HULUS\230, this being the correct
transformation for codepage 857) transformation, instead of doing it
according to ASCII.

2. If it is samba that does not preserve case (receive hulusi, transform it
to HULUSI), extend that portion of it to do international codepage specific
transformations instead of ASCII as it seems to be doing. (IF it is the
party at fault -- ie if it is receiving hulusi and transforming it to
HULUSI)

3. If it is indeed windows that is at fault, or the SMB protocol does not
preserve case, or something of that sort that Samba does not control --
meaning samba gets request for HULUSI and does the best it can by correctly
transforming it to hulus\215 and looking for it that way -- then, Samba
could have a workaround in the Turkish case, for the dotted/dotless i cases
where it looks for the other i .

The 3rd would be a workaround. The pair (i,\230) is distinct from (\215,I)
pair in Turkish and a word would be considered different if it had i vs.
\215.  It would cover every case, except when a sharename is different only
by virtue of dotted i vs. dotless i, so I guess it would work the great
majority of the time. Windows shares can be created with dotted i's and
dotless i's and be distinct, so I am hoping that it is not the Windows
portion of the communications that is going awry (also because it would be
impossible to change)..

Sorry for the longish message.

Best regards,
Deniz


----- Original Message -----
From: "Deniz Akkus Kanca" <deniz at arayan.com>
To: "Ryo Kawahara" <rkawa at lbe.co.jp>
Cc: <samba-technical at samba.org>
Sent: Tuesday, May 22, 2001 2:34 PM
Subject: Re: Problem with Turkish character share names -- how to modify?


> Hello,
>
> This problem occurs in samba 2.2.0 as well as my own Turkish patched
version
> of samba 2.0.7.
>
> I have sent in the Turkish support for samba and it has gotten included.
>
> The Turkish support works as in -- No problems with filenames, containing
> any Turkish character (dotted i, dotless i included, upper/lowercase, all
> combos). We have been using it at work with codepage 857 clients.
>
> The problem is with sharenames.
>
> This is probably what happens:
>
> Windows (codepage 857) reports a share name incorrectly:
>    a.     share name being hulusi, Windows asks for it as HULUSI
> (capitalized according to Ascii capitalization)
>    b.  Windows asking for it as HULUSI, samba, under Turkish charmap looks
> for hulus\215 or HULUSI and doesn't find it. (the share being hulusi or,
> capitalized, HULUS\230)
>
> I don't know almost anything about SMB protocol, so I am not sure whether
or
> not Windows is supposed to preserve case. If it did, the problem would be
> resolved (Windows asking for hulusi would solve the problem)
>
> Or, if windows can't be bothered to report it correctly, and samba is
> working under codepage 857:
> Samba looks for the share name in upper/lower case. (meaning when windows
> asks for HULUSI, it also tries looking for hulus\215. Under codepage 857,
it
> could also try the combinations HULUS\230, hulusi)
>
> If it is Samba that does not preserve case in windows requests it
receives,
> that could be corrected.
>
> I am willing to work on this issue, but knowing almost nothing about the
> internals of Samba code, I'd like someone to point me in the right
> direction. I am OK with reading other people's C code -- I just don't
think
> I can internalize all of Samba code in a hurry to solve this issue.
>
> Best regards,
> Deniz
>
>
>





More information about the samba-technical mailing list