Discussion:
What is NSRWS.EXE?
(too old to reply)
mike luther
2007-02-28 03:45:21 UTC
Permalink
Raw Message
Subject says most of the question. What is NSRWS.EXE and why does UNIMAINT and
so on find a missing link to this file in the \TMP directory time after time
over and over again though it is cleaned up and with other .INI file cleansing?


Thanks!
--
--> Sleep well; OS2's still awake! ;)

Mike Luther
mike luther
2007-05-07 04:27:54 UTC
Permalink
Raw Message
Self reply but I think important ..
Post by mike luther
Subject says most of the question. What is NSRWS.EXE and why does
UNIMAINT and so on find a missing link to this file in the \TMP
directory time after time over and over again though it is cleaned up
and with other .INI file cleansing?
Thanks!
Found source of this one and it is strange! Using an OS2 MCP2 system with
Seamonkey 1.1.1 High Mem latest, I chose to check into to Jan Wijk's DFSEE home
site to download the latest DFSEE 8.1.5 update. I did that. As well I
downloaded the WARPIN version. I had just before that gotten to the desk and
happened to run UNIMAINT which produced a totally clean INI file report on this
box. The only thing I did was to fire up Privoxy which I use, then SMK and
downloaded the update.


Since I've been trying to trace this for a long time now and nobody has had any
suggestions, I then ran UNIMAINT again. POOF! There is this strange NSRWS.EXE
OS/2 INI file error in it immediately after I downloaded the file from Jan's
site. And that has been absolutely there every time of late that I've had a
total lockup on OS/2 which is how I first noticed this.


So .. for curiousity, I used another OS/2 MCP2 system and carefully checked
with UNIMAINT to absolutely make sure this was the same test. Opened Privoxy
and SMK then went to Jan's site and downloaded another copy of the DFSEE 8.1.5
.ZIP file and the WARPIN version as well. I closed SMK and Privoxy after that,
then ran UNIMAINT again on this second box. POOF! There is the .INI file
error again.


So I did this again on a completely separate MCP2, Privoxy and SMK box the same
way. POOF! There is the .INI file error again on that box as well.


What is this issue? What is this executable for? What is going on here?


Thanks!
--
--> Sleep well; OS2's still awake! ;)

Mike Luther
Rich Walsh
2007-05-07 05:27:23 UTC
Permalink
Raw Message
Post by mike luther
What is this issue? What is this executable for? What is going on here?
Using xfix, I found a reference to nerws.exe in my temp folder along
with references to nsrws files with these extensions:

asp apsx cab gif html jpg js log m3u pdf pls und unf wax xls zip

Given what you did to get your reference, I suspect they're all
associated in some way with the mozilla browsers. However, it
isn't mozilla itself because the string "nsrws" can't be found
anywhere in the source tree.

I would think that the next logical step is simply to have your temp
folder open before you open your browser to see if you can spot one
or more of these files as they come & go.
--
== == almost usable email address: rich AT e-vertise.com == ==
___________________________________________________________________
|
| New! Cameraderie v1.5
Rich Walsh | an organizer & downloader for your digital camera
Ft Myers, FL | http://e-vertise.com/misc/camera15.zip
___________________________________________________________________
mike luther
2007-05-07 18:33:56 UTC
Permalink
Raw Message
Wonderful!
Post by Rich Walsh
Using xfix, I found a reference to nerws.exe in my temp folder along
asp apsx cab gif html jpg js log m3u pdf pls und unf wax xls zip
Given what you did to get your reference, I suspect they're all
associated in some way with the mozilla browsers. However, it
isn't mozilla itself because the string "nsrws" can't be found
anywhere in the source tree.
I would think that the next logical step is simply to have your temp
folder open before you open your browser to see if you can spot one
or more of these files as they come & go.
At least someone else has seen this now. I may be nuts but not certifiably so
at this point, chuckle. Hold the suggestion as to the temp folder until the
end of this, OK?


Yep, and I didn't mean in any way to implicate Jan's URL site. Based on your
message I tried exactly the same download technique with one MCP2 box I have
with SMK 1.5 beta latest. Surprise! No NSRWS contamination in it with the
download.


OK .. looking back at months of trying to trace this strange total lockup
potential issue I have a very strong statistical inference with this and
potentially something possibly related to WARPIN. In my notes I have a fair
number of pointers to having worked, somehow, with WARPIN after which this
appears. However this is the first time I have a specific combination of the
use of SMK and WARPIN. In this case, WARPIN wasn't even used. All I did was
use SMK to download the .WPI file, which the SMK is used in all the profiles to
simply treat it as a file and download it to the hard disk.


OK, when you suggest that I have the temp folder open while I do this, I'm a
command line varmint from the op system stone age. I've never even thought
about doing this objectively, grin. Are you suggesting that I open up the temp
folder as a part of the Connections Folder drill down? Then arrange my Desktop
so that it, which should be empty when we start, might be coerced by OS/2 to
objectively show that file object in it to appear during the download via SMK?
And thus to give us a visual portrayal of the fact that SMK is either doing
this or that a given URL at the other end of the process is trying to stuff
this into the \temp directory as part of something?


Now a remote stuffing incident would be a huge item for an OS/2 afficianado as
I see it? Specially if that remote stuffing were an OS/2 executable which
could be prevoked remotely to do something on remote command. You Tu? Wry grin..
--
--> Sleep well; OS2's still awake! ;)

Mike Luther
William L. Hartzell
2007-05-07 20:28:00 UTC
Permalink
Raw Message
Post by mike luther
Wonderful!
Post by Rich Walsh
Using xfix, I found a reference to nerws.exe in my temp folder along
asp apsx cab gif html jpg js log m3u pdf pls und unf wax xls zip
Given what you did to get your reference, I suspect they're all
associated in some way with the mozilla browsers. However, it
isn't mozilla itself because the string "nsrws" can't be found
anywhere in the source tree.
I would think that the next logical step is simply to have your temp
folder open before you open your browser to see if you can spot one
or more of these files as they come & go.
At least someone else has seen this now. I may be nuts but not
certifiably so at this point, chuckle. Hold the suggestion as to the
temp folder until the end of this, OK?
Yep, and I didn't mean in any way to implicate Jan's URL site. Based on
your message I tried exactly the same download technique with one MCP2
box I have with SMK 1.5 beta latest. Surprise! No NSRWS contamination
in it with the download.
OK .. looking back at months of trying to trace this strange total
lockup potential issue I have a very strong statistical inference with
this and potentially something possibly related to WARPIN. In my notes
I have a fair number of pointers to having worked, somehow, with WARPIN
after which this appears. However this is the first time I have a
specific combination of the use of SMK and WARPIN. In this case, WARPIN
wasn't even used. All I did was use SMK to download the .WPI file,
which the SMK is used in all the profiles to simply treat it as a file
and download it to the hard disk.
OK, when you suggest that I have the temp folder open while I do this,
I'm a command line varmint from the op system stone age. I've never
even thought about doing this objectively, grin. Are you suggesting
that I open up the temp folder as a part of the Connections Folder drill
down? Then arrange my Desktop so that it, which should be empty when we
start, might be coerced by OS/2 to objectively show that file object in
it to appear during the download via SMK? And thus to give us a visual
portrayal of the fact that SMK is either doing this or that a given URL
at the other end of the process is trying to stuff this into the \temp
directory as part of something?
Now a remote stuffing incident would be a huge item for an OS/2
afficianado as I see it? Specially if that remote stuffing were an OS/2
executable which could be prevoked remotely to do something on remote
command. You Tu? Wry grin..
One thought came to mind is the possibility that you might have a
default action defined for WPI ending files? It is possible for you to
select to run WARPIN upon downloading those files. Check Preferences ->
Navigator -> Helper Applications.
--
Bill
Thanks a Million!
Rich Walsh
2007-05-07 21:06:14 UTC
Permalink
Raw Message
"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.
--
== == almost usable email address: rich AT e-vertise.com == ==
___________________________________________________________________
|
| New! Cameraderie v1.5
Rich Walsh | an organizer & downloader for your digital camera
Ft Myers, FL | http://e-vertise.com/misc/camera15.zip
___________________________________________________________________
mike luther
2007-05-08 00:19:35 UTC
Permalink
Raw Message
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
Rich Walsh
2007-05-08 05:37:15 UTC
Permalink
Raw Message
Post by mike luther
Post by Rich Walsh
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.
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!
I recognize that in your response you acknowledged that this ini entry was
probably only part of the problem. Still, I'm reminded of the fellow who mixed
Scotch & water, drank it, and got drunk. Then, he mixed bourbon & water, drank
it, and got drunk. Finally, to confirm his suspicions, he mixed wine & water,
drank it, and still got drunk. Ah ha, he concluded, _water_ gets you drunk!

You found one handle entry for a file you couldn't identify, determined that
it was present after every lockup, and concluded that it is, in some way,
intimately involved in your very unfortunate situation.

Have you considered the fact that this entry is also present when you _don't_
have any lockups? Are you aware that virtually anyone who uses Peter's builds
of SeaMonkey & Firefox has at least one such entry because both browsers use
the exact same code to retrieve icons?

The ongoing thread in the mozilla group indicates that there's a real issue
with SeaMonkey causing lockups - an issue that just isn't seen with Firefox.
If one browser has a problem and the other doesn't, does it seem probable
that the culprit is code they both use?
--
== == almost usable email address: rich AT e-vertise.com == ==
___________________________________________________________________
|
| New! Cameraderie v1.5
Rich Walsh | an organizer & downloader for your digital camera
Ft Myers, FL | http://e-vertise.com/misc/camera15.zip
___________________________________________________________________
mike luther
2007-05-08 12:50:13 UTC
Permalink
Raw Message
Understood..
Post by Rich Walsh
Post by mike luther
Post by Rich Walsh
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.
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!
I recognize that in your response you acknowledged that this ini entry was
probably only part of the problem. Still, I'm reminded of the fellow who mixed
Scotch & water, drank it, and got drunk. Then, he mixed bourbon & water, drank
it, and got drunk. Finally, to confirm his suspicions, he mixed wine & water,
drank it, and still got drunk. Ah ha, he concluded, _water_ gets you drunk!
You found one handle entry for a file you couldn't identify, determined that
it was present after every lockup, and concluded that it is, in some way,
intimately involved in your very unfortunate situation.
Have you considered the fact that this entry is also present when you _don't_
have any lockups? Are you aware that virtually anyone who uses Peter's builds
of SeaMonkey & Firefox has at least one such entry because both browsers use
the exact same code to retrieve icons?
The ongoing thread in the mozilla group indicates that there's a real issue
with SeaMonkey causing lockups - an issue that just isn't seen with Firefox.
If one browser has a problem and the other doesn't, does it seem probable
that the culprit is code they both use?
Also understood is the information you post that SMK has the problem, from
public comment summary, yet Firefox does not. And that I'm not properly
dealing with my thoughts about how to 'prove' things by elimination of this
vector in the source, because I'm not looking at what all that might en_tail.


In humor, acknowledging your humor, I'm not alcohol oriented at all. But of me
you remind me of my priceless Father, long gone now. In high school in the
'20's he came across a drunken man, passed out on the street lying next to the
curb. He created a chain of paper clips holding a slip of paper on it on which
he had written a few words, then hung it around the man's neck and went on.
The words he wrote; "Little man, you've had a busy day!"


And in more technical humor here, another suggestioneer has perhaps seen me
with that around my neck and added a few words of encouragement! Again,
technical humor, but likely very important, 'perhaps we should see if this is
just an overdue issue while we're in the library, that we are missing we don't
know we are missing. A substitute librarian might get us an easier faster
answer in less time.. next time we all binge here!'


Old Fido puppy is waking up, carefully reading the paper scrap .. agrees!

;)
--
--> Sleep well; OS2's still awake! ;)

Mike Luther
Rich Walsh
2007-05-09 06:05:17 UTC
Permalink
Raw Message
Post by mike luther
And in more technical humor here, another suggestioneer has perhaps seen me
with that around my neck and added a few words of encouragement! Again,
technical humor, but likely very important, 'perhaps we should see if this is
just an overdue issue while we're in the library, that we are missing we don't
know we are missing. A substitute librarian might get us an easier faster
answer in less time.. next time we all binge here!'
If my response struck you as harsh or abrasive, then I do apologize -
it certainly wasn't intended to be.

If you still harbor any suspicions about my WPS additions, there's
an easy way to test this hypothesis. In your SeaMonkey directory,
you'll find rwsutil07.cmd. With _none_ of the mozapps from Peter
running (i.e. SMK, FX, TB), run that script and choose option #1
to deregister the RWS07 WPS class. Then, rename RWSSRV07.DLL.
If you have other mozapps from Peter, you'll need to rename or
delete the RWSSRV07.DLL in each app's directory to ensure the
class doesn't get reregistered.

SMK will still create a temporary file for a given extension
(basename 'moztmp') but it won't try to communicate with the WPS
(IIRC, this code pre-dates my efforts). Be aware that if your
temp folder is open, the WPS may create a handle for moztmp.???
on its own, so keep it closed.

If this appears to resolve the lockup problem, then please let me
know so I can investigate further.
--
== == almost usable email address: rich AT e-vertise.com == ==
___________________________________________________________________
|
| New! Cameraderie v1.5
Rich Walsh | an organizer & downloader for your digital camera
Ft Myers, FL | http://e-vertise.com/misc/camera15.zip
___________________________________________________________________
mike luther
2007-05-09 13:34:15 UTC
Permalink
Raw Message
Not at all offended!
Post by Rich Walsh
If my response struck you as harsh or abrasive, then I do apologize -
it certainly wasn't intended to be.
If you can't have fun solving problems life would be a real mess, grin. That's
why I added the humor note at the start to make sure you knew I didn't think it
was harsh or abrasive. Nor is anything posted here by myself intended to be
harsh or abraisive to anyone.
Post by Rich Walsh
If you still harbor any suspicions about my WPS additions, there's
an easy way to test this hypothesis. In your SeaMonkey directory,
you'll find rwsutil07.cmd. With _none_ of the mozapps from Peter
running (i.e. SMK, FX, TB), run that script and choose option #1
to deregister the RWS07 WPS class. Then, rename RWSSRV07.DLL.
If you have other mozapps from Peter, you'll need to rename or
delete the RWSSRV07.DLL in each app's directory to ensure the
class doesn't get reregistered.
OK - see that in the directory.
Post by Rich Walsh
SMK will still create a temporary file for a given extension
(basename 'moztmp') but it won't try to communicate with the WPS
(IIRC, this code pre-dates my efforts). Be aware that if your
temp folder is open, the WPS may create a handle for moztmp.???
on its own, so keep it closed.
OK and .. in humor here again, grin .. since I'm not so 'objective' in my
training, let me check something here. When you note that, "if your temp
folder is open ..", what that means is that if I have a folder opened for it
from the Connections folder .. or .. if I have an OS/2 or DOS-VDM window open
to it during execution of SMK? Which is how the 'handle' can get there when
OS/2 is handling the 'overhead' for a such open 'folder'?


I'm trying to learn here Rich. Normally I never have the temp file area open
at all either as a folder or from a command line, unless I really want to look
inside it. And from what I've seen over all these years, many things can wind
up there from SMK use, especially from botched downloads, other forms of
actions. Much of the time these things in it will show to be zero length.
What I will do, with nothing else running, will be to clean out the \temp
directory itself of 'files'. Then I'll run UNIMAINT to test for anything in
the .INI files which it thinks shouldn't still be involved -- there or otherwise.


Thus if how I understand what you've suggested is what needs to be done, as
well as the above before we start this test .. that's what I'll do. And from
there ..
Post by Rich Walsh
If this appears to resolve the lockup problem, then please let me
know so I can investigate further.
I'll post the results. This could take a while! As originally noted, once I
found out I could clean out that .INI file from the temp directory with
UNIMAINT, I've never seen this hard lockup again. So the longer I go without
posting here what that would mean is the longer it has gone without happening.


Now .. in humor here again, OK? Every time I pick up a shovel to dig in the
dirt, I have to get a handle on things, grin. But sometimes the dirt gets on
my hands when I am digging and it is hard to let go the handle depending on
what was in the dirt! I'm not very good at digging in dirt, so told me! And
is this issue maybe somewhat like that? What I'm wondering about is if, in the
action of doing whatever isn't 'finished' with this process which leaves the
handle in the .INI files that UNIMAINT finds, that this might cause a lockup?
That there is still a handle relationship that isn't maybe closed or 'handled'
properly, sticking around, if you will, thus causing the op-system confusion
leading to the lockup?


Which wouldn't be an issue if the whole little icon deal was working as
intended. With the complete correct LIBC workings as planned? Again .. this
level of OS/2 life is far beyond my awareness. I'm trying to learn here.
--
--> Sleep well; OS2's still awake! ;)

Mike Luther
James J. Weinkam
2007-05-08 17:54:28 UTC
Permalink
Raw Message
Post by Rich Walsh
"We have met the enemy and they are us" (_Pogo_, sometime in the '80s)
It had to be way before that. Walt Kelly died in the early seventies.
William L. Hartzell
2007-05-09 01:49:58 UTC
Permalink
Raw Message
Post by James J. Weinkam
Post by Rich Walsh
"We have met the enemy and they are us" (_Pogo_, sometime in the '80s)
It had to be way before that. Walt Kelly died in the early seventies.
I think the quote was from the early 30's, referring to the new deal,,
much repeated. This says it from the 60's.
<http://www.bartleby.com/59/3/wehavemetthe.html>
--
Bill
Thanks a Million!
Ilya Zakharevich
2007-05-09 12:12:12 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Rich Walsh
Post by Rich Walsh
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.
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?

Puzzled,
Ilya
Paul Ratcliffe
2007-05-09 16:09:48 UTC
Permalink
Raw Message
On Wed, 9 May 2007 12:12:12 +0000 (UTC), Ilya Zakharevich
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
Ilya Zakharevich
2007-06-12 18:30:04 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
Post by Paul Ratcliffe
On Wed, 9 May 2007 12:12:12 +0000 (UTC), Ilya Zakharevich
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
I do not see why you consider this as any kind of evidence. Do you
always run WPS? Do you always run WPS from the same boot partition?
Do you ever use a removable drive? Do you ever reformat a drive? Do
you ever restore .INI files?

What I say is very simple: if WPS is running, and you delete a file,
WPS should know about it.

Hope this helps,
Ilya
Paul Ratcliffe
2007-06-13 00:05:29 UTC
Permalink
Raw Message
On Tue, 12 Jun 2007 18:30:04 +0000 (UTC), Ilya Zakharevich
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
I do not see why you consider this as any kind of evidence.
Huh? I really don't see what point you are attempting to make. The WPS doesn't
always delete the handle. If it did, there wouldn't be loads of dead handles
would there?
Post by Ilya Zakharevich
Do you always run WPS?
Yes. Don't you? If you aren't running it, how do you expect it to be notified
of files being deleted?
Post by Ilya Zakharevich
Do you always run WPS from the same boot partition?
Yes. What has that got to do with anything. If the WPS runs from a different
partition, then the system is booted from a different partition. I fail to
see what significance any of this has?
Post by Ilya Zakharevich
Do you ever use a removable drive?
For what? And what relevance does this have?
Post by Ilya Zakharevich
Do you ever reformat a drive?
Rarely. Same question.
Post by Ilya Zakharevich
Do you ever restore .INI files?
Almost never. I if do, I expect some inconsistency depending on what happened
between taking the copy and doing the restore.
Post by Ilya Zakharevich
What I say is very simple: if WPS is running, and you delete a file,
WPS should know about it.
Yes, it should and indeed it does know about it. How do you think it removes
entries from the container view of a folder? By magic?
What it doens't always (if ever) do is remove the relevant handle from the
.INI file.
Post by Ilya Zakharevich
Hope this helps,
As usual, you are obtuse to the point of irritability.
Ilya Zakharevich
2007-06-13 18:23:15 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
I do not see why you consider this as any kind of evidence.
Huh? I really don't see what point you are attempting to make. The WPS doesn't
always delete the handle. If it did, there wouldn't be loads of dead handles
would there?
Hmm, did you read what I wrote? If WPS is not running (or running
with different .INI files) when a file disappears, how would it delete
the handle? [E.g., when a file is deleted on a different computer?]
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Do you always run WPS?
Yes. Don't you?
Of course not. Time to time I need to go to a command-line boot.
Post by Paul Ratcliffe
If you aren't running it, how do you expect it to be notified
of files being deleted?
This is exactly my question TO YOU.
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Do you always run WPS from the same boot partition?
Yes. What has that got to do with anything. If the WPS runs from a different
partition, then the system is booted from a different partition. I fail to
see what significance any of this has?
Different INI files are use. The handle is deleted from a different database.
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Do you ever use a removable drive?
For what? And what relevance does Handles to files on removables get
A file can be deleted on a different computer.
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Do you ever reformat a drive?
Rarely. Same question.
Reformatting deletes files. Certainly you know about this?
Post by Paul Ratcliffe
Post by Ilya Zakharevich
What I say is very simple: if WPS is running, and you delete a file,
WPS should know about it.
Yes, it should and indeed it does know about it. How do you think it removes
entries from the container view of a folder? By magic?
What it doens't always (if ever) do is remove the relevant handle from the
.INI file.
In my experience, it does. [But I never did any direct experiment.
Did you?]

Hope this helps,
Ilya
Andreas Schnellbacher
2007-06-13 23:08:04 UTC
Permalink
Raw Message
Paul Ratcliffe wrote in article
Completely agreeing with Paul, I don't understand you either, so
Post by Paul Ratcliffe
Yes, it should and indeed it does know about it. How do you think
it removes entries from the container view of a folder? By magic?
What it doens't always (if ever) do is remove the relevant handle
from the .INI file.
In my experience, it does. [But I never did any direct experiment.
Did you?]
No, XWP does (or better: tries to do, but with reasonable result), if
any.
--
Andreas Schnellbacher
Paul Ratcliffe
2007-06-14 00:02:25 UTC
Permalink
Raw Message
On Wed, 13 Jun 2007 18:23:15 +0000 (UTC), Ilya Zakharevich
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
I do not see why you consider this as any kind of evidence.
Huh? I really don't see what point you are attempting to make. The WPS doesn't
always delete the handle. If it did, there wouldn't be loads of dead handles
would there?
Hmm, did you read what I wrote?
Of course I bloody well did, you arrogant shit. Several times. What do you
take me for?
The fact that you seem unable to express what you really mean is your problem.
Post by Ilya Zakharevich
If WPS is not running (or running
with different .INI files) when a file disappears, how would it delete
the handle? [E.g., when a file is deleted on a different computer?]
Obviously, it can't. This is SO obvious, I cannot comprehend why you are
asking it.
Post by Ilya Zakharevich
Post by Paul Ratcliffe
If you aren't running it, how do you expect it to be notified
of files being deleted?
This is exactly my question TO YOU.
That was not obvious from what you wrote.
Post by Ilya Zakharevich
Different INI files are use. The handle is deleted from a different database.
Obviously the WPS can only update the set of INIs in use at the time of the
deletion. This is also SO obvious I again cannot comprehend why you ask.
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Do you ever use a removable drive?
For what? And what relevance does Handles to files on removables get
A file can be deleted on a different computer.
Oh Christ, I'm getting sick of repeating myself. How do you expect another
machine to know this???
Post by Ilya Zakharevich
Reformatting deletes files. Certainly you know about this?
Well bugger me. Perhaps that's where I've been going wrong all this time.
Do you want me to include some <sarcasm> tags or shall we take those as read?
Post by Ilya Zakharevich
Post by Paul Ratcliffe
Post by Ilya Zakharevich
What I say is very simple: if WPS is running, and you delete a file,
WPS should know about it.
Yes, it should and indeed it does know about it. How do you think it removes
entries from the container view of a folder? By magic?
What it doens't always (if ever) do is remove the relevant handle from the
.INI file.
In my experience, it does. [But I never did any direct experiment.
Did you?]
So why when we run INI file cleaners like Xfix and Checkini etc. do we get
loads of dead file handles then? It is obvious that the WPS is not cleaning
up *properly* even when the situations you mention above do NOT occur.
Ilya Zakharevich
2007-06-14 15:24:47 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
Post by Paul Ratcliffe
Post by Ilya Zakharevich
Hmm, did you read what I wrote?
Of course I bloody well did, you arrogant shit. Several times. What do you
take me for?
The fact that you seem unable to express what you really mean is your problem.
Why do you think I was "expressing" anything? What I was trying to
achieve was intelligent *conversation*. It requires two. You did not
do your part; and as the following question shows, still not doing...
Post by Paul Ratcliffe
So why when we run INI file cleaners like Xfix and Checkini etc. do we get
loads of dead file handles then?
So you answer "yes" on all my questions; which shows that you know all
the reasons I listed. And you ask the same question again?!!!

Well, one more situation - which IMO is a bug in the current scheme -
is a WPS crash before the system .INI file is updated.
Post by Paul Ratcliffe
It is obvious that the WPS is not cleaning up *properly* even when
the situations you mention above do NOT occur.
Hmm, it is not obvious to me. But I never use WPS folders (except
desktop, or accidentally hitting C-W button in FC), so I could easily
miss something.

Hope this helps,
Ilya
Lars Erdmann
2007-06-13 22:31:11 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
Post by Paul Ratcliffe
On Wed, 9 May 2007 12:12:12 +0000 (UTC), Ilya Zakharevich
Post by Ilya Zakharevich
This does not ring right... When you delete a file, WPS *should* be
notified of this action, and it *should* delete the handle. Why, you
think, this does not happen?
Because reality tells us otherwise. Witness all the dead handles left in
the INI files.
I do not see why you consider this as any kind of evidence. Do you
always run WPS? Do you always run WPS from the same boot partition?
Do you ever use a removable drive? Do you ever reformat a drive? Do
you ever restore .INI files?
What I say is very simple: if WPS is running, and you delete a file,
WPS should know about it.
It does.
It calls DosOpenChangeNotify to register file paths and actions (see
next API) to monitor.
It calls DosResetChangeNotify to get returned a list of files and/or
directories that where added/deleted/changed/renamed since the last time
it was called (?)
If calls DosCloseChangeNotify to end notification.
(these are listed in \ddk\base\h\bsedos.h):

http://prog-gate.pp.ru/fido7.su.os2.prog/671.html


Problem is (I guess), the WPFileSystem class is acting sloppy in not
clearing the OS2SYS.INI.
"wpVerifyUpdateAccess" of WPFileSystem seems to be called when the
filesystem changes, see also here:

http://svn.netlabs.org/qtapps/browser/psi/trunk/src/tools/dirwatch/dirwatch_pm.cpp?rev=9&format=txt

Of course, booting to a commandline and adding/deleting a file cannot be
caught by WPS as it is not executing at the time of file/directory
manipulation.
But it would be possible to write a daemon that runs in the background
and clears the handles from OS2SYS.INI as soon as a file or directory is
deleted (that would even be the best solution).

Lars
Ilya Zakharevich
2007-06-14 15:35:52 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was sent to
Lars Erdmann
Post by Lars Erdmann
Problem is (I guess), the WPFileSystem class is acting sloppy in not
clearing the OS2SYS.INI.
This is not my experience. If I rename a file from a command-line
program, WPS definitely updates the handle. Do you say that if I
delete a file from a command-line, the handle is not updated?
Post by Lars Erdmann
Of course, booting to a commandline and adding/deleting a file cannot be
caught by WPS as it is not executing at the time of file/directory
manipulation.
But it would be possible to write a daemon that runs in the background
and clears the handles from OS2SYS.INI as soon as a file or directory is
deleted (that would even be the best solution).
I do not see why this is in any way reasonable. WPS knows about the
changes. WPS should do it.

How to protect against WPS crashes? For this, indeed, a separate
deamon looks as a best solution; but not standalone - a WPS slave.

E.g.: WPS pipes the change log to a deamon; the daemon writes log to
the disk as slowly as it wants.

When a new copy of WPS starts (after a crash), it asks daemon to
flush log to disk, reads it, UPDATES THE .INI file, restarts
daemon, and continues the normal operation.

:-( Of course, now it is too late to discuss...)

Yours,
Ilya
Ilya Zakharevich
2007-06-14 15:45:03 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich
Post by Ilya Zakharevich
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Lars Erdmann
Post by Lars Erdmann
Problem is (I guess), the WPFileSystem class is acting sloppy in not
clearing the OS2SYS.INI.
This is not my experience. If I rename a file from a command-line
program, WPS definitely updates the handle. Do you say that if I
delete a file from a command-line, the handle is not updated?
Thinking about this more, I think I might have seen this. And it may
be a feature, not bug...

[[Cannot check now, since the drat DSL modem at this location
accepts connections from OS/2 for 30 seconds only; since Win*
shows a notification "New hardware appeard: router FOOBAR" on
every cable connect, something cheesy is going on in background...
So I forced to connect via PuTTY...]]

E.g., *) I can move a part of a directory tree to a ZIP;
*) handles pointing to this directory subtree are now stale;
*) then, later, I can restore the ZIP, and handles "resurrect".

Since I may have used this effect several times, I cannot stop
thinking that this effect may have been intentional from the start.

Hmm...
Ilya
Lars Erdmann
2007-06-14 17:15:36 UTC
Permalink
Raw Message
Post by Ilya Zakharevich
[A complimentary Cc of this posting was sent to
Lars Erdmann
Post by Lars Erdmann
Problem is (I guess), the WPFileSystem class is acting sloppy in not
clearing the OS2SYS.INI.
This is not my experience. If I rename a file from a command-line
program, WPS definitely updates the handle. Do you say that if I
delete a file from a command-line, the handle is not updated?
Yes, that's what I mean. It does not act properly on deletion while it
acts OK on filename/dirname change.
Post by Ilya Zakharevich
Post by Lars Erdmann
Of course, booting to a commandline and adding/deleting a file cannot be
caught by WPS as it is not executing at the time of file/directory
manipulation.
But it would be possible to write a daemon that runs in the background
and clears the handles from OS2SYS.INI as soon as a file or directory is
deleted (that would even be the best solution).
I do not see why this is in any way reasonable. WPS knows about the
changes. WPS should do it.
Wrong. Any application that uses the API I mentioned knows about
file/directory changes. What happens is that these APIs call into the
IFS(es). The IFS tracks the changes to the filesystem and reports them
back to the application when the app calls DosResetChangeNotify (again,
a call into the IFS).
It's just that the WPS (to be more precise: PMSHELL.EXE) is one of these
apps that does that.
Post by Ilya Zakharevich
How to protect against WPS crashes? For this, indeed, a separate
deamon looks as a best solution; but not standalone - a WPS slave.
E.g.: WPS pipes the change log to a deamon; the daemon writes log to
the disk as slowly as it wants.
When a new copy of WPS starts (after a crash), it asks daemon to
flush log to disk, reads it, UPDATES THE .INI file, restarts
daemon, and continues the normal operation.
:-( Of course, now it is too late to discuss...)
No, it's much more simple. Since the WPS does not properly update
OS2SYS.INI on a file/dir deletion, the daemon can do it.
Since WPS does not do it, WPS and the daemon do not interfere with each
other.
The only problem I see is that DosOpenChangeNotify might not be able to
work recursively (specify only the root directory and you catch all
changes in all subdirectories).
Then you would need to call DosOpenChangeNotify with EVERY path you want
to monitor. That would not be feasable I guess.
For WPS (PMSHELL.EXE) it's easier: Whenever you open a folder,
(presumably) DosOpenChangeNotify is only called for that path.
Likewise, if you open a commandline CMD.EXE (presumably) calls
DosOpenChangeNotify only for that path and I would even think that it is
CMD.EXE that then properly updates OS2SYS.INI.


Lars
Ilya Zakharevich
2007-06-14 19:57:30 UTC
Permalink
Raw Message
[A complimentary Cc of this posting was sent to
Lars Erdmann
Post by Lars Erdmann
Post by Ilya Zakharevich
Post by Lars Erdmann
But it would be possible to write a daemon that runs in the background
and clears the handles from OS2SYS.INI as soon as a file or directory is
deleted (that would even be the best solution).
I do not see why this is in any way reasonable. WPS knows about the
changes. WPS should do it.
Wrong. Any application that uses the API I mentioned knows about
file/directory changes.
Are you sure that your information is *complete*? (I have never
checked this, but) what I've heard is that only one app at a time can
use these APIs...
Post by Lars Erdmann
No, it's much more simple. Since the WPS does not properly update
OS2SYS.INI on a file/dir deletion, the daemon can do it.
Since WPS does not do it, WPS and the daemon do not interfere with each
other.
The only problem I see is that DosOpenChangeNotify might not be able to
work recursively (specify only the root directory and you catch all
changes in all subdirectories).
Then you would need to call DosOpenChangeNotify with EVERY path you want
to monitor. That would not be feasable I guess.
For WPS (PMSHELL.EXE) it's easier: Whenever you open a folder,
(presumably) DosOpenChangeNotify is only called for that path.
I have no clue what you are talking about. I have no folders open
(except desktop); nevertheless WPS knows when I renamed
files-which-have-handles via Dos* APIs.
Post by Lars Erdmann
Likewise, if you open a commandline CMD.EXE (presumably) calls
DosOpenChangeNotify only for that path and I would even think that it is
CMD.EXE that then properly updates OS2SYS.INI.
I think you are confused. I do not discuss CMD.EXE; just write any
program which calls the Dos* APIs.

Hope this helps,
Ilya

Loading...