Python 2.2 unwise.exe
Robin Becker
un-install 2.2 prior to installing 2.2.1 I got an error saying it had
already been un-installed.
Tried the link in start menu and it said no unwise.exe was there.
Luckily I had a copy of unwise.exe on another machine. Copied into the
right place and it seems to have done the trick.
-Flat cats are not better than nested birds-ly yrs.-
Robin Becker
Stephen D Evans
installed 2.2.1 over the top of the existing 2.2. It works.
I had no problems uninstalling Python 2.2 on Windows 2000.
Stephen D Evans
"Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
news:ZkjnuIAB...@jessikat.fsnet.co.uk...
Tim Peters
> Anyone else had a problem un-installing 2.2 for win32? When I tried to
> un-install 2.2 prior to installing 2.2.1 I got an error saying it had
> already been un-installed.
>
> Tried the link in start menu and it said no unwise.exe was there.
Yes, I've seen this happen several times, but only under Win9X, not Win2K.
Which flavor of Windows are you using? So far you're the only other one to
report it. I can't account for it: the installer definitely creates
UNWISE.EXE in the right place (the root of your Python tree), but sometimes
"it goes missing" later. Exactly when and why remains a mystery to me. It
may be related to unplanned <ahem> system crashes.
Robin Becker
<tim...@comcast.net> writes
Installed under C:\Python; system is Win2k. I installed win32all-146
after Python-2.2, but didn't save backups.
I have a couple of other things installed eg Numeric-20.3 and PIL, but
nothing that came with an installer. I don't remember anything untoward
about the Python-2.2 install.
The unwise.exe was just not there for some reason.
--
Robin Becker
Tim Peters
> Installed under C:\Python; system is Win2k. I installed win32all-146
> after Python-2.2, but didn't save backups.
>
> I have a couple of other things installed eg Numeric-20.3 and PIL, but
> nothing that came with an installer. I don't remember anything untoward
> about the Python-2.2 install.
>
> The unwise.exe was just not there for some reason.
Crud, I was hoping it was unique to Win9x. "Just not there for some reason"
is the same thing I've seen. I build the PLabs Windows installer, so I get
more practice with it than anyone else. "Just not there" has definitely
happened more than once after I've run an install and verified that
UNWISE.EXE is indeed exactly what and where it should be after the install
completes. Yet two hours or two weeks or two months later, it's plain gone.
Nothing else is missing when this happens, just UNWISE.EXE. That's all I
know for sure about it ... OK, I'm going to change UNWISE.EXE in my install
trees to read-only. Maybe that will catch whatever is deleting it in the
act. Heh: Just did that. UNWISE.EXE still existed in my 2.1 and 2.2
trees, but had already gone missing in my experimental 2.3 tree.
windows-is-an-adventure-ly y'rs - tim
PS: The PLabs Windows installer is a zip file of a kind WinZip knows how to
read. That is, e.g., you can open Python-2.2.1.exe directly from WinZip.
If UNWISE.EXE goes missing for you, you can extract it from the installer
.exe, using WinZip. Extract the file UNWISE32.EXE into the root of your
Python installation, and rename it to UNWISE.EXE. Then the "Uninstall
Python" shortcut should work fine again. Using an older version of
UNWISE.EXE from somewhere else may or may not work completely; the newer
version we ship knows how to perform rollbacks, and does a much more
complete job of undoing *all* Windows install fiddling than older versions
are capable of doing.
Bengt Richter
[...]
_anything_ done to/with unwise.exe gets logged in the security log, that might
be even more effective than just read-only (which afaik won't prevent a rename or move
(or attrib ;-) BTW, could it have gone invisible rather than missing?). You could scan
the whole disk (including normally hidden files) for a file with identical data, I suppose.
You should also be able to control access better than simple read-only, e.g., by giving
ownership to a special user that reserves all the permissions except read. The most privileged
admin can always get around it, but a ISTM a program would have to have been written to do
the special steps, and I don't know that it could avoid getting caught in the log anyway.
In any case, such a prog doesn't seem like the kind of cause being hunted here.
Regards,
Bengt Richter
Jimmy Retzlaff
> Crud, I was hoping it was unique to Win9x.
It's gone on my development workstation (WinXP Pro) but still on my
server (Win2K Server). The most obvious difference in usage between the
two is that I'm often installing/uninstalling/reinstalling various
extensions (Win32all, Numeric, wxPython, PIL, mx, etc.) on my WinXP
machine. Any chance some package is also using Wise and treating
unwise.exe as its own? It appears Win32all 146 uses Wise but it has its
own unwisepw32.exe in site-packages. Has it always been so careful? That
suggests protection if this is the problem (e.g., timscoolunwise.exe).
Jimmy
Steve Holden
news:mailman.1018734147...@python.org...
> [Robin Becker, on unwise.exe vanishing]
> > Installed under C:\Python; system is Win2k. I installed win32all-146
> > after Python-2.2, but didn't save backups.
> >
> > I have a couple of other things installed eg Numeric-20.3 and PIL, but
> > nothing that came with an installer. I don't remember anything untoward
> > about the Python-2.2 install.
> >
> > The unwise.exe was just not there for some reason.
>
> Crud, I was hoping it was unique to Win9x. "Just not there for some
reason"
> is the same thing I've seen.
Oh, crap. Same thing's happened on my Win2k installation. I habitually run
Windows Explorer with "show hidden files", so I know it's really disappeared
and isn't just in hiding.
Perhaps we're being unwise relying on this software? I wonder whether some
other uninstall of a Python related component might be causing this?
regards
Steve
David Bolen
It happened to me under WinNT 4.0 SP4. As far as I can recall I
haven't had any abnormal shutdown of this system since installing 2.2.
I ended up just copying the unwise.exe from a Python 2.1 directory and
it un-installed fine. UnWisePW32.exe was present - just unwise.exe
was missing.
It seems to be in place ok at the moment from the 2.2.1 install. But
I can't say that I ever checked or noticed if it was properly present
after first installing 2.2.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Robin Becker
My unwise.exe is now gone as of Tuesday 10:00 am.
I had a hard crash Monday morning.
--
Robin Becker
Robin Becker
writes
>On the office machine well I installed Python 2.2.1 last Friday evening.
>My unwise.exe is now gone as of Tuesday 10:00 am.
>
>I had a hard crash Monday morning.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\UNWISE.EXE]
"x"=hex:0c,00,00,00,00,00,00,00,06,00,00,00,00,00,00,00
"DllPatch-x"=""
I have no idea what this means, but perhaps it might
have something to do with the problem.
--
Robin Becker
Tim Peters
> On the office machine well I installed Python 2.2.1 last Friday evening.
> My unwise.exe is now gone as of Tuesday 10:00 am.
>
> I had a hard crash Monday morning.
Did you have a previous version of 2.2 on your machine, and uninstall it
before installing 2.2.1?
On a clean Win2K Pro box, I'm finally able to provoke this (or at least one
of its causes) reproducibly, via:
1. Boot the box.
2. Install 2.2.1.
3. Uninstall 2.2.1.
4. Install 2.2.1 again. Note that \Python22\UNWISE.EXE is there.
5. Reboot the box (just logging off and on again isn't enough).
6. Now \Python22\UNWISE.EXE no longer exists.
Robin Becker
<tim...@comcast.net> writes
>[Robin Becker]
>> On the office machine well I installed Python 2.2.1 last Friday evening.
>> My unwise.exe is now gone as of Tuesday 10:00 am.
>>
>> I had a hard crash Monday morning.
>
>Did you have a previous version of 2.2 on your machine, and uninstall it
>before installing 2.2.1?
>
sadly no. On the office Win2k machine I had 2.1.2 previously. On the
home Win2k machine I had 2.2 and discovered that unwise.exe was missing
on Saturday when I tried to uninstall in order to reinstall with 2.2.1.
>On a clean Win2K Pro box, I'm finally able to provoke this (or at least one
>of its causes) reproducibly, via:
>
>1. Boot the box.
>
>2. Install 2.2.1.
>
>3. Uninstall 2.2.1.
>
>4. Install 2.2.1 again. Note that \Python22\UNWISE.EXE is there.
>
>5. Reboot the box (just logging off and on again isn't enough).
>
>6. Now \Python22\UNWISE.EXE no longer exists.
>
>
>
--
Robin Becker
Bengt Richter
>[Robin Becker]
>> On the office machine well I installed Python 2.2.1 last Friday evening.
>> My unwise.exe is now gone as of Tuesday 10:00 am.
>>
>> I had a hard crash Monday morning.
>
>Did you have a previous version of 2.2 on your machine, and uninstall it
>before installing 2.2.1?
>
>On a clean Win2K Pro box, I'm finally able to provoke this (or at least one
>of its causes) reproducibly, via:
>
>1. Boot the box.
>
>2. Install 2.2.1.
>
>3. Uninstall 2.2.1.
>
What happens if you shut down and boot here?
(I'm wondering if there's a deferred delete waiting for a reboot
which doesn't get cleared by the re-install at 4.)
>4. Install 2.2.1 again. Note that \Python22\UNWISE.EXE is there.
>
>5. Reboot the box (just logging off and on again isn't enough).
>
Deferred delete happens during reboot??
>6. Now \Python22\UNWISE.EXE no longer exists.
>
>
>
Regards,
Bengt Richter
Tim Peters
> On a clean Win2K Pro box, I'm finally able to provoke this (or at
> least one of its causes) reproducibly, via:
>
> 1. Boot the box.
>
> 2. Install 2.2.1.
>
> 3. Uninstall 2.2.1.
>
>
> 5. Reboot the box (just logging off and on again isn't enough).
>
For anyone playing along, this particular way of provoking the problem
appears stoppable via inserting step 2a:
2a: Delete this line from near the end of \Python22\INSTALL.LOG:
Delete in-use files: On
Bengt Richter
That's good info, but you're not suggesting that as a solution, are you?
ISTM that would be interfering with a normal and legitimate function of
installers/uninstallers.
IOW, I'm guessing uninstall at 3 uses that line to decide whether to
talk to windows about files it can't delete because they're locked as in use.
Uninstallers talk to windows and say "delete this and that when you get chance
while they're not locked." That "while" occurs by design at a point in the boot
process, before those files get a chance to be locked again for some reason.
Likewise, an installer may call for deferred replacement of a file when the
file can't be deleted.
I'm guessing it takes a reboot or some special program operation to flush pending
deletes. Thus the uninstall at 3 would leave a normal pending delete, but apparently
there is no special programming in the install at 4 to deal with it. So windows remembers
until the next boot. However the install at 4 seems to have replaced unwise.exe (or
it scheduled a boot time replace, and windows got the now two pending operations out of order?)
In any case, after 4 there seems to be either a single pending delete or an out of order
pair of delete unwise.exe and delete/replace unwise.exe at 5, and the boot triggers it,
hence 6.
At least that's my theory.
Why do you think windows always wants you to reboot after installing, after all?
Seems like better file transaction stuff could have been designed into he system ;-/
Regards,
Bengt Richter
Tim Peters
> appears stoppable via inserting step 2a:
>
> 2a: Delete this line from near the end of \Python22\INSTALL.LOG:
>
> Delete in-use files: On
[Bengt Richter]
> That's good info, but you're not suggesting that as a solution, are you?
It's the only workaround I have, so sure.
> ISTM that would be interfering with a normal and legitimate function of
> installers/uninstallers.
It's no big deal. It's *intended* to clean up in-use DLLs (like
python22.dll), but they're normally not in use at uninstall time, and
without that line in INSTALL.LOG Wise should visibly complain to the user
that it can't delete an in-use file if one is in fact in use. I believe
it's a Wise bug that it both does manage to clean up UNWISE.EXE (with or
without that line), yet arranges to do a delete-on-reboot dance on
UNWISE.EXE anyway.
Note that we never had a report of a missing UNWISE.EXE before we moved from
Wise 5 to Wise 8. One thing that changed along with that was including the
"Delete in-use files" line starting with Wise 8.
> ...
> At least that's my theory.
> Why do you think windows always wants you to reboot after
> installing, after all?
I know all that stuff, but it doesn't solve the problem. Getting rid of the
"delete in-use files" gimmick does. I don't know whether that's the *only*
problem here, though (Robin Becker seems to think not, but I don't believe
everything I read on Usenet <wink>).
Tim Peters
>
> 2. Install 2.2.1.
>
> 3. Uninstall 2.2.1.
[Bengt Richter]
> What happens if you shut down and boot here?
Nothing visible. The entire \Python22 directory is gone (including
WISE.EXE) immediately after completing step 3. After a reboot, it's still
gone <wink>.
> (I'm wondering if there's a deferred delete waiting for a reboot
> which doesn't get cleared by the re-install at 4.)
Of course. But since the only relevant file in use at the time UNWISE.EXE
is running *is* UNWISE.EXE, and Wise already got rid of it, it appears to be
a Wise bug that it arranges to delete, at the next reboot, any file named
\Python22\WISE.EXE the user happens to create after Wise already got rid of
the original.
Bengt Richter
>> 1. Boot the box.
>>
>> 2. Install 2.2.1.
>>
>> 3. Uninstall 2.2.1.
>
>[Bengt Richter]
>> What happens if you shut down and boot here?
>
>Nothing visible. The entire \Python22 directory is gone (including
>WISE.EXE) immediately after completing step 3. After a reboot, it's still
>gone <wink>.
>
Sure. But the point was to see if the deferred delete got flushed so that
reinstalling could succeed without thereafter still having a deferred
delete to get hammered with on the next reboot after that.
>> (I'm wondering if there's a deferred delete waiting for a reboot
>> which doesn't get cleared by the re-install at 4.)
>
>Of course. But since the only relevant file in use at the time UNWISE.EXE
>is running *is* UNWISE.EXE, and Wise already got rid of it, it appears to be
>a Wise bug that it arranges to delete, at the next reboot, any file named
>\Python22\WISE.EXE the user happens to create after Wise already got rid of
>the original.
>
This is the delete which I wanted to see if it got flushed with the otherwise
unnecessary reboot at 3a.
If so, you could just specify reboot after uninstall before the next install as a fix,
I would think.
Regards,
Bengt Richter
Tim Peters
> ...
> If so, you could just specify reboot after uninstall before the
> next install as a fix, I would think.
Rebooting Windows is a PITA for users, and if someone is confused enough to
try to uninstall Python while they're using Python, I'd rather they get a
complaint from Wise. That is, silent deletion of in-use files is a dubious
idea for Python anyway, and that it tickles a Wise bug (Wise uses a
different mechanism to get rid of UNWISE.EXE -- they shouldn't be trying to
do a redundant at-reboot delete of this specific file) nails it for me.
Robin Becker
<tim...@comcast.net> writes
.....
>I know all that stuff, but it doesn't solve the problem. Getting rid of the
>"delete in-use files" gimmick does. I don't know whether that's the *only*
>problem here, though (Robin Becker seems to think not, but I don't believe
>everything I read on Usenet <wink>).
well actually I think your hypothesis is correct.
--
Robin Becker
Tim Peters
> Getting rid of the "delete in-use files" gimmick does [eliminate
> the vanishing unwise.exe problem, under at least one scenario]. I
> don't know whether that's the *only* problem here, though (Robin
> Becker seems to think not, but I don't believe everything I read
> on Usenet <wink>).
[Robin Becker]
> well actually I think your hypothesis is correct.
Well, it was definitely *a* cause, and the sole cause of every vanishing act
I was able to provoke. I reported it as a bug to Wise, and changed our
installer to stop using the "delete in-use files" gimmick for the duration.
Thanks for bringing it up, Robin! While I've been seeing this happen for a
year, the lack of any other report caused me to file it in my "huh --
something mysterious happened on Win98 -- so what else is new" bin.
BTW, if UNWISE.EXE goes missing for someone, see whether a file named
GLB1A2B.EXE
is sitting in your temp directory. The Wise uninstaller creates this, and
except for the name it's identical to UNWISE.EXE. That's how they manage to
delete UNWISE.EXE during a normal uninstall without a reboot (it can't
delete itself because Windows won't let anyone delete an open file; instead
UNWISE.EXE makes a renamed clone of itself in the temp directory, and spawns
the clone at the end of the uninstall process to get rid of itself). You
can move GLB1A2B.EXE to your Python root, rename it to UNWISE.EXE, and all
the normal ways of uninstalling should work again.
Tim Peters
> ...
> (Wise uses a different mechanism to get rid of UNWISE.EXE -- they
> shouldn't be trying to do a redundant at-reboot delete of this
> specific file)
Wise agreed, and quickly built a new version of UNWISE.EXE that doesn't have
this problem. This leaves one other small problem: how do we manage to
magically replace a hundred thousand or so vulnerable UNWISE.EXE's already
installed in Python directories on Windows boxes? It's times like this I'm
glad Python installs secret backdoors on Windows boxes so Guido can control
them from the comfort of home.
it's-typing-in-all-your-names-that's-the-bitch-ly y'rs - tim
David Bolen
> Wise agreed, and quickly built a new version of UNWISE.EXE that doesn't have
> this problem. This leaves one other small problem: how do we manage to
> magically replace a hundred thousand or so vulnerable UNWISE.EXE's already
> installed in Python directories on Windows boxes? It's times like this I'm
> glad Python installs secret backdoors on Windows boxes so Guido can control
> them from the comfort of home.
I don't see how to fix the current installed base, but since they'll
only get hit - thus it really only matters - when they go to install a
new version (and thus will be downloading it), perhaps publishing a
copy of UNWISE.EXE along with the Python downloads would at least
provide a workaround if they don't have another copy somewhere on
their system to use.
Either that or try to see if the installation script could be made to
clean out any pending delete operation as part of the installation?
Hernan Foffani
> Wise agreed, and quickly built a new version of UNWISE.EXE
> that doesn't have this problem. This leaves one other
> small problem: how do we manage to magically replace a
> hundred thousand or so vulnerable UNWISE.EXE's already
> installed in Python directories on Windows boxes?
> It's times like this I'm glad Python installs secret
> backdoors on Windows boxes so Guido can control them
> from the comfort of home.
I was going to ask if you can upload it to python.org, but
since you're going to patch the 100K PCs all by yourself...
> it's-typing-in-all-your-names-that's-the-bitch-ly y'rs - tim
one less to type: Hernan Foffani / IP: 217.126.144.119
;-)