Messages in this thread | | | From | "Petr Vandrovec" <> | Date | Wed, 26 Jul 2000 12:21:51 MET-1 | Subject | Re: BUG REPORT : IPX (Novell) uppercase convert error with |
| |
> > (1) disable 'Lowercase DOS filenames' > > (2) do not use OS/2 namespace (use NFS namespace instead) > > (3) fix your server's LCONFIG.SYS to contain CP866 and not CP437 uppercase > > table > Petr, I repead once more: I am not a programmer, I am project manager. I don't > know where LCONFIG.SYS placed and how to uninstall OS/2 namespace from server > and to replace it by NFS namespace. I have no time to learn Novell. And I
It is simple. Leave OS/2 namespace as is and simple do 'load nfs.nam' 'add namespace nfs to volume sys' (you can remove this namespace using vrepair).
> AFRAID to change anything in Novell because of many peoples in our company > works with it. And I have no reasons to pay money for programmer who know
Then disable lowercasing names in Linux and you are done. What's wrong with this solution?
> About NFS. I don't want to use NFS in Novell server due to > security reasons.
It is not NFS as network filesystem. It is NFS namespace, in Unixware called Unix namespace. It allows you to create real UNIX names, case sensitive, names can contain "*", "?", "\", "..." and all others, in other namespaces disallowed, characters.
> About server's bug. As I understand, the problem is that > Novell OS/2 namespase does not support lower russian letters. But we need the > future of some russian letters for our work. So we had to install OS/2 > namespace. It is an instruction to all users to use only upper russian letters, > but this is users - they periodically forgot about this. It's incorrect, but > it's work.
Yes. You cannot instruct NCP to do this automagically, I'm afraid. But if you disable lowercasing of DOS namespace entries, it will work for you same way as Windows do...
> But I think about thousands of other users of 2.4.0, who can collide with the > same problem and will swear on russian, swedish, japan or others mat. Your will > repead the explanations to all of them?
Yes, I will. Currently there is almost no reason for having this option anymore, as all new Novell servers have LONG namespace installed from time 0, and all other servers has it added for >3 years to support Windows long filenames... Also DOS is rarely used, so owning namespace == DOS almost does not exist anymore...
> About 3.12. I don't know how many Novell 3.12 is in the world today. But > I know, for examle, that computer net of our russian parlament works on 3.12. > I think that 3.12 and other old novell soft will stay long time, because of > standard reaction of any chief of any company. When it's a offer to buy new > Novell instead of old: "Old Novell works? It's no reason to spell money for > new". This is my own position as a boss too: 3.12 works very good, and it's no > reasons for me to spend money or time to it's upgrading, until it is > ABSOLUTELY nesessary.
But you see that old Novell does not work completely correctly. And I believe that it can be simple fixed by Novell releasing OS2.NAM which will (for example) retrieve uppercasing table from DOS's COUNTRY=... command. The you'll add COUNTRY=...,866,... to your config.sys and voila... Or by creating specific OS2.NAM which will contain CP866 as uppercasing table. If Novell can send me sources of OS2.NAM from 3.12, I believe that I can fix it in few hours (and another part of this problem is to persuade vrepair to not remove these additional characters during repair, as it uses CP437 too...)
> Primakow (our former premier and one of biggest politics of Russia) sad to me > that he want to try Linux instead of Win98 for his daily work. This man isn't a > programmer at all, he is a diplomat. How you will explain to him about > namespaces and other programmer's things? He will try Linux, and if it will > not work, he returned to Windoz. And that's all.
As I said. There is feature, which other peoples finds useable. Japaneese are glad that they can now use EUC-JP on ncp filesystem and UTF8 inside Linux... If this feature does not work for you, disable it...
> Your and your collegues al Linux kernel programmers carry a greate > responsibility for the preservation of this good quality of Linux. If it is a > bug in some type of processor - so, Linux must to do to correct the influence > of this bug (your know better than I that it is usial practice in kernels). > If it is some bug on external servers - so, Linux must have tools to ignore > this bug. And so on.
It has. Disable lowercasing of DOS filenames. Or disable use of 'OS2' namespace at mount time using 'ncpmount -N os2 ....'. It is like User: 'When I do "touch AA" and then "cat aa" on ncp filesystem, "cat" did not say 'file not found', but printed contents of "AA". Fix this!' Me: 'Add NFS namespace to server. This namespace is case sensitive.' User: 'I do not want to change my server configuration. It works for me. Please fix this!'
> My user's aim is to inform your about detected problems of my > concret type of soft and hard, in that purpose that other users in future will > not collide them. Your right is to estimate this information and decide what > to do: to consider it or ignore, if my concret soft/hard configuration is very > specific.
If I'll find how to retrieve case sensitivity table from server, I can try to detect this condition in NCPFS. But currently there is no other way than
for i in 1...255; if touch toascii(i) continue; // cannot create at all... if [ ! -f tolower(toascii(i)) ]; then DOESNOTWORK=1; fi rm -f toascii(i) if [ "$DOESNOTWORK" = "1" ]; then break; fi done if [ "$DOESNOTWORK" = "1" ]; then disable_lowercasing(); fi As you can see, it requires write access to volume, creates couple of temporary files and will not work correctly with multibyte encoding (DBCS edition of Novell server probably refuse to create partial multibyte char, so test will pass, but (see IDE/ATA thread) Linux kernel should not emit invalid multibyte characters without additional buggy software...)
> P.P.S. By the way, when I try to compile the kernel in first time, I switch on > all NLS in kernel, and gcc says to me about error in cp936 codepage. Because of > I don't need it, I swithed off it. But what is this error, I don't know.
Which compiler do you use? My Debian-woody 'gcc version 2.95.2 20000220' compiled one from 2.4.0-test5-pre4 without any complaint. It generated 128224 bytes module nls_cp936.o, which can be happily insmod-ed. Which kernel did you tried? (I have currently enabled all kernel codepages + nls_abc and neither complained. I compiled all as modules. Did you try to compile this codepage into kernel?) Best regards, Petr Vandrovec vandrove@vc.cvut.cz
- 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/
| |