Author Topic: JFS failing in a disastrous way - without the user knowing  (Read 31459 times)

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #30 on: December 02, 2022, 06:07:44 pm »
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

  • Hero Member
  • *****
  • Posts: 4990
  • Karma: +111/-1
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #31 on: December 02, 2022, 10:39:28 pm »
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

  • Hero Member
  • *****
  • Posts: 1353
  • Karma: +69/-0
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #32 on: December 03, 2022, 10:32:26 am »
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.
« Last Edit: December 03, 2022, 10:50:07 am by Lars »

Andi B.

  • Hero Member
  • *****
  • Posts: 852
  • Karma: +11/-2
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #33 on: December 03, 2022, 11:30:12 am »
Quote
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
« Last Edit: December 03, 2022, 11:32:09 am by Andi B. »

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #34 on: December 03, 2022, 04:01:12 pm »
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.

  • Hero Member
  • *****
  • Posts: 852
  • Karma: +11/-2
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #35 on: December 03, 2022, 05:09:59 pm »
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

  • Hero Member
  • *****
  • Posts: 1353
  • Karma: +69/-0
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #36 on: December 04, 2022, 11:31:36 am »
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.

  • Hero Member
  • *****
  • Posts: 852
  • Karma: +11/-2
    • View Profile
Re: JFS failing in a disastrous way - without the user knowing
« Reply #37 on: December 04, 2022, 12:34:31 pm »
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

  • Jr. Member
  • **
  • Posts: 68
  • Karma: +3/-1
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: JFS failing in a disastrous way - without the user knowing
« Reply #38 on: December 04, 2022, 11:28:25 pm »
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