Re: BUG REPORT : IPX (Novell) uppercase convert error with

From: Petr Vandrovec (VANDROVE@vc.cvut.cz)
Date: Wed Jul 26 2000 - 05:32:26 EST


> > (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/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:21 EST