I go pogo - you go pogo - we all go pogo!
Post by Rich Walsh"We have met the enemy and they are us" (_Pogo_, sometime in the '80s)
Ever since you started posting about this, I've been uncomfortable
because "nsrws" is part of the name of the WPS-integration features
I added to the mozapps, i.e. a C++ class named nsRwsService. However,
I couldn't put the pieces together because I _knew_ there was no .exe
involved. Today, I opened my temp folder while doing downloads to see
what would happen. As I watched these files come & go, it hit me.
One of the features I added is supposed to display an appropriate
icon in the download dialog (e.g. that brown box icon for .wpi).
Sadly, Peter had to disable this for other reasons, but the underlying
mechanism is still at work.
It takes the extension of the download, appends it to the string
"nsrws", and creates a file by that name (e.g. nsrws.wpi). It then
queries the WPS for that file object's icon; after making a copy of
the icon, it deletes the file. Because this process references the
file as a WPS object, the WPS creates a handle for it.
So, I'm to blame for your mystery file. But, as you see, it's nothing
to worry about. OS/2's "security through obscurity" remains unbreached.
BTW... Since the WPS can't tell one "f:\temp\nsrws.wpi" from another,
you'll never get more than one handle per file extension. And, since
the code caches the icons it fetches, it only creates one such file
per extension per session.
Yeah, curiously, we are all 'us' in OS/2 a lot more than we think, grin!
But the real reason this is before me is in almost *EVERY* case of my complete
OS/2 system lockups I've see in three different MCP2 boxes over some time now,
which require a complete power off switch and total CHKDSK cleanup for
recovery, I've found this involved and still in the .INI file corruption after
the recovery!
More important, every time I've found it and cleaned it out of the .INI file
with UNIMAINT then the boxes have never locked up! I was taking a lot of
these curious lockups until I hit this. Then after all the clean outs, I've
never had them since. These lockups, once the .INI file operation grub is in
there, take place even though I'm not at the desktop. I'll leave the system
with it there for a day or several hours. Come back and the whole box is
locked. The key failure box is one which is solidly involved in COMM port I/O
and data logging operations at all times, together with some TCP/IP concurrent
applications as well. Disabling PRIVOXY as an always running operations
stopped some of it. Privoxy's handling of its always open log file and however
it also internally caches log entries appears to be not good in many ways, but
that is only part of the problem.
I've found out through brute force whomping that if I increased the write cache
size for the HPFS file system up to at least 16 from the default 4 in
CONFIG.SYS, I can stop some of this, but it only delays the onset. I've found
out that it looks like if an OS/2 .INI file change is taking place when this
strange one happens, then it can REALLY be bad news. In this case on two
different boxes, one time each, I got into the really bad your HPFS file system
has failed error was there. And it took a complete utility diskette boot with
that CHKDSK operation to clean up the file system corruption it dishes out.
And it's only been of thought to me recently that SMK was involved in this
specific pathway to lockups. That although a number of people have posted
strange lockups with SMK. Now, seeing what you posted, at least some of the
answer might be here. But not all of it, would be my guess Rich. The disk
corruption with .INI file changes and cache glitches has very rarely been in
there for a lot longer than what I betcha trips this we see here. In this case
it's probably just that a trigger mechanism is what happens here.
So even though it appears that it is an innocent single entry in the OS/2 .INI
files, I suspect that a lot more of a problem is here before us. But I have no
idea on what the complete failure mechanism might be. Of threaded operations,
I have no idea on what might happen if the file system has some curious
mis-thread during the weaving of the cloth over something like this. But from
a pure logged failure major series of this, at least in my world it is.
And I'm so thankful that you read this and might be in a position to help get
it out of the way. My guess is that others who have the strange lockups when
downloading the .WPI files have no idea of it. And likely don't use an .INI
file cleanup tool on a very, very regular basis so they'd never make the
connection to it either.
Thank you so kindly for your efforts. The real beauty of OS/2 are the
fantastic people who so kindly keep contributing to us all, out of the goodness
of their hearts and souls.
--
--> Sleep well; OS2's still awake! ;)
Mike Luther