JFS failing in a disastrous way - without the user knowing

[OS4User]

Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

It is very good suggestion. You proved that unicode.sys  is vital for system with JFS.

[Dave Yeo]

Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

It is very good suggestion. You proved that unicode.sys  is vital for system with JFS.

OTOH, I went 18 months without unicode.sys with en_US locale. It was only when I found this,

Code: [Select]

2-17-22 11:04a         <DIR>      0 ----  Gel
 2-17-22 11:13a         <DIR>      0 ----  Sessions effac
 2-17-22 10:58a         <DIR>      0 ----  Verwijderde sessies
[\code]
instead of this,
[code]
2-17-22 11:04a         <DIR>      0 ----  Gelöschte Sitzungen
 2-17-22 11:13a         <DIR>      0 ----  Sessions effacées
 2-17-22 10:58a         <DIR>      0 ----  Verwijderde sessies

That I investigated. Seems without unicode.sys, you can write and read umlauts etc as long as always without unicode.sys.

[Lars]

You can. Until you end up with a system where you can no longer remove directories where directory names were manipulated without UNICODE.SYS being loaded. That messes up the unicode character string on a very basic filesystem level. And then, DFSee is your last resort to rectify that.

If you always use en_US locale, you will very likely NEVER run into this problem, because codepage 437 is the default for about anything that relates to an ASCII string in OS/2. This is about people that either have to use a different codepage or where the OS installation installs a different codepage as the primary codepage. For a german OS/2, codepage 850 is installed as the default (with 437 as a secondary codepage) even though codepage 437 would also do for most of the things (german umlauts are also supported with codepage 437 and even have the same byte value as in codepage 850).
In short, for a few special characters, codepage 437 and 850 are identical. For the lower 128 characters, 437 and 850 are also identical (and that includes 0-9 a-z A-Z : \ .).
For a french codepage this will be comparable but certainly not for any cyrillic codepage.
Which also makes it clear why no modern operating system is using codepages anymore.

I repeat: this is an absolute NOGO for a commercial operating system.

[Andi B.]

I repeat: this is an absolute NOGO for a commercial operating system.

Do you wanna send this complain to IBM or ArcaNoae? :-)

Lars, I absolutely understand your frustration. Really.

But IBM will never change this I fear. I also fear AN will not change the basics of any file system. Moreover I fear they have a lot of stuff to do with higher priorities. But we will see how they respond to the ticket.

For all with access to the ticket system - I think it's worth to read Stevens conclusion on this problem. The ticket should be linked now. Thanks Dave.

Edit - this ticket I meant. Scroll down to the end. https://mantis.arcanoae.com/view.php?id=1223

[Andreas Schnellbacher]

For all with access to the ticket system

As an Arca Noae customer, I have access to the tickets. But #1223 seems to be hidden for me, while Martin's #3364 works for me.

[Andi B.]

Sorry to hear that. This ticket was from 2017 and dealt with the very same problem. But there it leads to a trap when reading DVDs. It's closed since a long time. I commented there back then. Maybe that's the reason why I see it. I don't want to copy text from there but the bottom line is - it would be good if the original CPUTEMP warpin package would have been tested better. But people make mistakes. The problems with this package are 1) it deletes UNICODE.SYS and 2) it puts rdmsr.sys at the top of config.sys. It should be better places after the IFS lines.

Unfortunately wic -t does not test such failures in a package. But a modified CPUTEMP package should be available from here - ftp://digi.os2.snc.ru/pub/SystemLoad/CPUTemp-20170504-2.zip. Mind I didn't test this. Use it on your own risk! Or search for the latest AND remember to check what an installer does with your config.sys.

By the way - this is a very good example that's not always a good idea to save old versions of packages/drivers...

I think it's not a big problem to copy this one sentence from the ticket - 'The only way for traps to never happen is for humans to never make
mistakes.'

[Lars]

Being an OS/2 user is a little bit like being a drug addict:
you know that it's bad for your health but you just can't let go.

[Andi B.]

Completely agree with you Lars ;-)

One note I want to add here - since a while I always check my config.sys (diff) after some installer wanted to change it. There are so many installers which changes libpath and/or path. At least since all these ported software luckily we have, it's a big problem when some installers put something in front of the %unixroot% entries.

[Digi]

it would be good if the original CPUTEMP warpin package would have been tested better

This issue was fixed a long time ago, right after the first reported problem. I recommend using the latest CPUTemp from the SystemLoad package: http://os2.snc.ru/product-SystemLoad.html