> kernel 2.4.0test4 / patch test5pre3 compiled with option
> FileSystems->Network File systems->Lowercase DOS filnames ="on"
>
> then
>
> transformation of russian names and recognition of files/directories in Novell
> volume is wrong.
User configuration error. Which 'iocharset' and 'codepage' parameters
you passed to 'ncpmount'? Doing translation from koi8 <-> cp437 can
really lead to unexpected results.
> New kernel sometimes understand files with russian names as
> directories and directories with russian names as files in Novell volume. But
> the others (in russian too) are recognized correctly.
Please, please, try it with bash and 'ls'. I believe that it is KFM bug,
that if they cannot open file because of your Linux uses different
lowercasing table than server, entry returned by getdents can result
in stat() of that entry returning -ENOENT. Your KFM then ignores this
error and uses file/dir info from previous one.
If this bug turns file -> dir, KFM then chokes when doing chdir. Try
telnet/ping to your machine when it does not react to ctrl-alt-backspace
or ctrl-alt-del (mine X server ignores ctrl-alt-del, btw; if I (just
by accident) run X and I want to reboot, I must hit ctrl-alt-backspace
and then ctrl-alt-del). Also, what about alt-sysrq-K?
> Some russian directories under 2.4 became
> lowcase (from uppercase), other became uppercase from lowercase, but there
> are some some unchanged (unconverted) russian names.
I do not see any example of being uppercase in your gifs and I do not believe
that this happens. Lowercasing of course happens, you specifically asked
for this in kernel config. As I said, use NFS namespace on server - it
allows all characters in range 1..46, 48..255 in filenames and has not
problem with screwed server case-insensitivity as it is case sensitive.
> It was default NLS in "koi8-r" in both cases: the 1-st (unworkable) and 2-nd
> (workable).
You should not use DOS or OS/2 namespace if configuration of your server
does not match configuration of your client.
If you do this, you break assumption that open("PANIC") and open("panic")
(replace PANIC/panic with non-US-ASCII characters) both either fails or
suceeds. Even worse, if server knows PANIC, in sequence of open("PANIC"),
open("panic") both can suceed, as second open finds (locally) already
existing dentry, but in open("panic"); open("PANIC") first can fail, as
server converts "panic" to something else, such as QWERT... With
NW4.11/NW5 you could decide which codepage you'll use on server. With
NW3.12 I'm under impression that if you selected to use Netware character
set (and not DOS), it will work a bit better... But it was option asked
when you created volume :-(
If you can find oops in your syslog files, or you see directories as
files under 'ls -l', mail me again. Otherwise I believe that it is pilot
error and KFM bug, as I was not able to recreate it here, even if
I created filename which contains all 254 different characters (I
can see -ENOENT error when my external codepage is not CP852 (as my
server has), but nothing goes wrong...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
P.S.: ncpfs has currently almost nothing to do with IPX, as it can
use both UDP or TCP, if you have server recent enough... I almost
overlooked your posting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:16 EST