OS/2, eCS & ArcaOS - Technical > Storage
JFS failing in a disastrous way - without the user knowing
OS4User:
--- Quote from: Lars on December 02, 2022, 03:48:55 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).
--- End quote ---
It is very good suggestion. You proved that unicode.sys is vital for system with JFS.
Dave Yeo:
--- Quote from: OS4User on December 02, 2022, 06:07:44 pm ---
--- Quote from: Lars on December 02, 2022, 03:48:55 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).
--- End quote ---
It is very good suggestion. You proved that unicode.sys is vital for system with JFS.
--- End quote ---
OTOH, I went 18 months without unicode.sys with en_US locale. It was only when I found this,
--- Code: ---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
--- End code ---
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.:
--- Quote ---I repeat: this is an absolute NOGO for a commercial operating system.
--- End quote ---
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:
--- Quote from: Andi B. on December 03, 2022, 11:30:12 am ---For all with access to the ticket system
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version