OS/2, eCS & ArcaOS - Technical > Storage

JFS failing in a disastrous way - without the user knowing

(1/8) > >>


I thought, I'd share this info with everybody.

Initial info:
0) as a standard case that is likely true for 99.9 % of all OS/2 systems in use today, my system/boot partition is JFS formatted
1) a long time ago, I had installed eCS as german NLS version. What that means for this error case is that some standard directories of the WPS are created with umlauts in their directory names, for example, "Desktop" becomes "Arbeitsoberfläche" in german.
2) as some of you might know, JFS.IFS saves its directory and file names in UNICODE and relies on the services of the UNICODE.SYS driver to properly convert between UNICODE and the default ASCII character set in use because effectively, the IFS interface only supports ASCII directory and filenames. The consequence of that is that you should NEVER hop between different character sets (by using the "chcp" command) when you create directories or files that have special characters in them (anything beyond the US437 character set).
3) for various reasons I have multiple boot configurations with different "config.sys" files, managed by the QSINIT selection menu. These files have different names: config.sys, config.smp, config.w4 etc.

Recently I decided to install this package:
That was the first error, because I have an AMD CPU and therefore this package was useless for me :-)

What followed next was the "cputemp" WPI package updating the default "config.sys" file by placing a driver into it. As it turned out later, it would not only add a driver load entry but also, apparently due to a bug in WarpIn (I later extracted the install script from the WPI file and found nothing wrong or suspicious in it), would remove the load line for UNICODE.SYS from the config.sys file. Because I had booted from a boot configuration that used another "config.sys" file (named, say "config.smp") this problem did not become apparent for as long as I was booting in the alternate boot configuration.

Eventually I booted into the standard boot config using file "config.sys". The base boot of loading all drivers and IFS (including JFS.IFS) went by without any problem but eventually, I was presented by the XWorkplace message that my desktop directory could not be found.
I was not too worried and suspected a simple OS2.INI or OS2SYS.INI corruption and decided to restore this set of files from a boot a few days earlier.

But on the next reboot, the error showed up again. From the commandline of the temporary desktop that had been created I decided to look directly at the filesystem naming of directories and files. And yes, "Arbeitsoberfläche" had been corrupted at the umlaut character. I then took the bad choice (in hindsight) and attempted to rename the directory back to what it was but it turned out that I was unable to do so. I was also unable to delete or rename that directory with any other tool like File Commander.
I decided to copy the desktop from a backup folder and was successful but intimidating enough, now I had two directories with the very same name "Arbeitsoberfläche" (on filesystem level !) but one of it could neither be renamed nor deleted. To remember: UNICODE.SYS driver was not loaded at this point.

It dawned on me that something had gone terribly wrong with the file system.Using DFSee, I triggered a chhdsk for the next reboot. The chkdsk would end without error but now I would directly run into a trap right after chkdsk was done. This was repeatable.

Fortunately, I had a completely different "development" boot partition that was completely intact (and both, UNICODE.SYS and JFS.IFS propery loading). And I had DFSee. But that was installed on the JFS partition that I could not boot from. Fortunately, as turned out later, that did not matter. The "broken" partition had directory naming problems but was intact as such and therefore I was able to readd the UNICODE.SYS load entry to "config.sys" on the "broken" partition.

I fired up the "development" boot partition and started DFSee. In one of its extended menus I found the possibility to rename directories and files on a very low file system level (so to say). Apparently, DFSee understands all low level structures of JFS and can directly overwrite sector content.

Subsequently it turned out that not only "Arbeitsoberfläche" had been "renamed" disastrously but also all OTHER DIRECTORIES below "Arbeitsoberfläche" that contained umlauts (yes there are quite a few directories below the "Desktop" directory ...).

For each of the affected directories, I had to hop back and forth between giving them an intermediate name like "Arbeitsoberflxxxx" and "Arbeitsoberfläche" to force the proper directory name (intermediate reboots required). After multiple reboots and some traps I was finally able to restore the partition to an acceptable state, but I had to recreate quite a few directories under the "Desktop" directory and move things to their proper place.

I think it would at least be helpful if JFS.IFS would, ideally already on bootup, report a warning if it fails in using UNICODE.SYS services instead of reporting nothing. That would have pointed me to the problem and would have saved me hours of work.
(I can understand that JFS.IFS will need to be able to continue nonetheless because otherwise you would not be able to fix the config.sys file and readd the UNICODE.SYS load entry ...).

This behaviour is surely an absolute NOGO for a new user (unless you only accept english speakers or people using the US/UK NLS version as new users).

Mike Kölling:
Hi Lars,

Thanks for your detailed explanation about the JFS issue without the unicode.sys driver.
As a German user of ANOS with a lot of Umlaute, because I renamed a lot of the originally English named folders to common German names, I think it might help me to avoid similar waste of time for finding out the root cause of the problem.

Thanks and Greetings from Potsdam / Germany,

Dariusz Piatkowski:
Oh dude...I feel your pain!!!

1st of all, glad that you recovered, but yeah, as I read your post I likewise had the tell-tale feeling of "butterflies" in my stomach, old memories came back here.

A few years back I made the move from HPFS386 to JFS, but since this was NOT a fresh install I managed to convert stuff (standard XCOPY partition move approach, etc.) while UNICODE.SYS was NOT preceeding the JFS call in CONFIG.SYS. Bottom line being the NEW system was quite usable, appeared to work just fine, but soon enough strange things started to happen and eventually I had a major JFS problem on my hands.

In this case the root cause was my unfamiliarity with true JFS requirements and the fact that I missed tossing UNICODE.SYS into my CONFIG.SYS ahead of the JFS IFS call and ahead of the partition move process itself.

Your root cause is quite different from that, but at the time of my troubles I do recall thinking to myself: "well, if the darn thing is THAT important why isn't the IFS at least shouting - should really scream at me though - when it finds it missing?".

Andi B.:
These Umlaut problem hits us OS/2 users since the beginning. The root of the problem is IMO IBMs decision to translate important folders to something with special characters (Arbeitsoberfläche). A lot of us where bitten by this ages before JFS arrived when we simply played with codepage settings in config.sys or CHCP. It's the same with HPFS(386). When you change the codepage setting in config.sys, chances a good that on the next reboot you're Desktop is lost/destroyed. Only difference is - we learned not to do this. Never ever play with codepage setting (at least the first one). We also have to learn not the delete unicode.sys when using JFS. Maybe Martin can delete these package from hobbes. Or when it's really a warpin issue then I think it is solved in current releases. I remember reading about that problem (deleting unicode from config.sys) a while ago.

--- Quote --- because I renamed a lot of the originally English named folders to common German names
--- End quote ---
I hope you don't make this problem worse and don't use umlauts. Even if the meaning of the translation sounds not as exact as it could be, it's far better to use another word and circumvent any special character in (system relevant) file/folder names.

Dave Yeo:
I ran into the same issue, excepting with a English install, there were just some MP3's with umlauts. In my case everything was fine, including the umlaut files being fine, until I booted to a different install, where those file names became garbage (actually I forget if it was umlauts or other special characters). Took a while to figure out it was a missing unicode.sys and once I did figure it out, I renamed the problem files without unicode.sys installed.
This is a known problem that was reported to Digi long ago and he fixed the problematic CONFIGSYS="DEVICE=?:\OS2\rdmsr.sys | UNIQUE" line, which upon not finding rdmr.sys, replaced the first line containing .sys, usually unicode.sys. There's an issue, but it is private. Remy filed it. Unluckily it was quite a while before it was uploaded to Hobbes.


[0] Message Index

[#] Next page

Go to full version