Basilisk/Pale Moon uninstallers don't delete all program files/folders

[WouterK]

During uninstallation of Basilisk or Pale Moon from Windows, not all program files and folders are deleted from "C:\Program Files[ (x86)]".

Steps to reproduce for Basilisk:

1:
If the latest Basilisk (2020.10.28) isn't already installed on the system, run its installer.
I've tested basilisk-2020.10.28.win32.installer.exe on:
- Windows 7 32-bit
- Windows 7 64-bit
- Windows 10 64-bit
I've tested basilisk-2020.10.28.win64.installer.exe on:
- Windows 7 64-bit
- Windows 10 64-bit
For "Setup Type", accept the default "Standard".
Whether or not you uncheck "Launch Basilisk now" doesn't matter, but for simplicity do uncheck it.
After installation, verify (e.g. with Windows Explorer) that "C:\Program Files[ (x86)]\Basilisk" contains 95 files.

2:
Make sure Basilisk isn't running and no application (e.g. Windows Exporer or a terminal window (cmd.exe)) is locking Basilisk's program folder.
Then uninstall Basilisk via "Control Panel" -> "Programs and Features" (in Windows 10 alternatively via Settings -> "Apps & features").
Expected result: "C:\Program Files[ (x86)]\Basilisk" is completely removed.
Actual results:
a. Only 7 files are removed (so 88 files remain):
basilisk.exe
install.log
undate-settings.ini
defaults\pref\channel-prefs.js
uninstall\helper.exe
uninstall\shortcuts_log.ini
uninstall\uninstall.log
b. Only 2 subfolders are removed:
defaults
uninstall
And no, rebooting doesn't help...

Pale Moon behaves very similarly: in any case on Windows 7 and 10 64-bit palemoon-28.15.0.win64.installer.exe removes only palemoon.exe and the same 6 other files and 2 subfolders.

In view of the phasing out of 32-bit Basilisk (cf. https://forum.palemoon.org/viewtopic.php?f=61&t=25397), it would be nice if this could be fixed in/before Basilisk's last 32-bit version.

[Tharthan]

For the record, Moonchild (and given the known state of my computer, I wouldn't have mentioned this except that the original poster here already brought it up), when I went to uninstall 32-bit Basilisk from my computer, the uninstaller didn't function properly for me either.

I ended up having to manually delete a lot of the files. Not a big deal, but since the original poster brought it up, I thought that I would note that there were problems with Basilisk's uninstaller for me as well.

[Moonchild]

We actually looked at that with Issue #1594 (UXP) and I tested proper uninstallation at the time to verify UAC and removal worked. I'm surprised it's not working... and as selectively as it's doing this now according to your reports is even stranger.

[WouterK]

I've done some more tests on Window 7 64-bit, installing + uninstalling older 64-bit Pale Moon versions (i.e. palemoon-28.n.n.win64.installer.exe):
The program folder was completely removed by 28.0.0, 28.3.0 and 28.4.0.
However, 28.4.1, 28.5.0 and 28.7.0 only deleted the 7 files that I mentioned in my original post.
So the problem started in 28.4.1 (released 2019-03-27), and as far as I can see has never disappeared since then.

Some remarks about Issue #1594 (UXP):

The OP there states:

However it doesnt actually uninstall the program. The full Pale Moon directory is left under Program Files untouched.

Considering my tests, it seems "untouched" wasn't accurate: presumably the OP had simply missed that 7 files were removed.
In line with the (erroneous) assumption that the program folder was left untouched, wolfbeast then suggested that the cause of the problem was a lack of elevation:

Confirmed. Seems the uninstaller doesn’t try to run elevated from a standard user account, giving it no rights to remove files in \Program Files

But the fact that 7 files are removed, suggests that something else was (and is) wrong.
So I don't know what to think of Moonchild's comment here:

I tested proper uninstallation at the time to verify UAC and removal worked.

Is there something different about my (and perhaps some other people's) Windows configuration that makes things go wrong?
(At least In my case it can't be caused by interference from an anti-virus program: I've never used any of these.)

[Moonchild]

The issue referenced is obviously not what the problem is here. No, none of the files were removed with that not fixed because none of the files could be touched by an unelevated account.

I just referred to it because it was a rather recent check of the uninstaller's operation and worked as-intended after the patch.
I don't know what YOUR problem is (yet) but it's not that.

[Moonchild]

Having a relatively small window (28.4.0-28.4.1) does help. Ill have a closer look at those changes

EDIT: nothing stands out, at all, in what was changed between those versions...

[WouterK]

I may have found the cause of the problem:
First I double-checked that it is indeed between 28.4.0 (good) and 28.4.1 (bad).
Then I compared their respective install.log files:
The one for 28.4.0 contains two lines that the one for 28.4.1 doesn't:

Code: Select all

  Installed File: C:\Program Files\Pale Moon\precomplete
  Installed File: C:\Program Files\Pale Moon\removed-files

Then I looked at the content of these files:
- "precomplete" contains a list of "remove <filename>" and "rmdir <directory>" lines.
- "removed-files" contains a bare list of mostly folder names.
So I guessed that it's the absence of "precomplete" that prevents the deletion of the files and folders mentioned in "precomplete".
And indeed, when I removed "precomplete" from the program folder of 28.4.0, then uninstalled 28.4.0, this uninstallation suddenly failed the same way that 28.4.1 did, i.e. actually only uninstalling the 7 files mentioned in my original post.
So probably the problem with 28.4.1 and later has been the absence of "precomplete". (I'm not sure how relevant "removed-files" is.)

[New Tobin Paradigm]

Precomplete huh.. I'll get my eyes on it in a bit once zi wake up as well.

[Moonchild]

interesting... means it's a release engineering issue; the zip archive of that version -does- have the precomplete and removed-files files, but the installer does not.

I think I can figure out what's going on now and fix it. Thanks for helping me pinpoint the cause!

[New Tobin Paradigm]

NSIS has the call to create precomplete str8 up though. I documented this fact at one point. I am nof sure why nsis wouldn't have it inside the core directory. Only other thing I csn think of is it may get clobbered on mar update.

Also, if it is a version with zip packaging it is pre-uxp packaging. Very confusing. As soon as I can will my self out of my warm bed to kick the heat on I shall investigate.

[Moonchild]

It's actually not something that's wrong with the code in the tree, Tobin. Scratched my head on that one for a while too because there's no change to any of that in the version diff window.

I found the culprit. It's the script for code-signing setup.exe -- requires unpacking the installer and repacking it, and the repacking had a call to the packer (7z) with argument *.* in good traditional fashion to pack all files. But that doesn't work very well for files that don't have an extension.
I didn't run into this problem when testing the UAC changes because I was working with a dev build, unsigned, of course.

Simple fix, simply use a single * instead and it'd all be peachy.

As an aside, this would also only be a problem if you installed it with the installer and then uninstalled it again without having an update installed via the internal updater (which would drop the required files in place, too, since they are inside the mar).

[New Tobin Paradigm]

Ah ok. Cause I was like I know I followed up with precomplete before being an issue in some places and not in others when I was doing packager-uxp so I was like.. Didn't I already fix this.. Did I mess something else?!

Remaining question is why are people uninstalling?

[Moonchild]

Remaining question is why are people uninstalling?

I can ask the same question why I end up removing 100-150 sync accounts every week that have gone unused for 3 months.

[New Tobin Paradigm]

The common reason given, of course, is me. I am the reason for all issues. However, and despite my historical self importance, I don't think so.

Context from the OP is 32bit Basilisk so moving to 64bit?

[WouterK]

As an aside, this would also only be a problem if you installed it with the installer and then uninstalled it again without having an update installed via the internal updater (which would drop the required files in place, too, since they are inside the mar).

To save bandwidth I always download any new version of any software only once, then distribute it to my various OSes myself.
So I have never used Basilisk or Pale Moon's internal updater. If I understand you correctly, this "deviant" behavior might explain why this problem hit me but perhaps not many other people.

Context from the OP is 32bit Basilisk so moving to 64bit?

Off-topic:
Correct!
Well, partially at least:

My main machines are two high-end desktops on which I use both Basilisk and Pale Moon, all 64-bit of course.
But I also have a 10-year old netbook (nowadays with 2 GiB RAM), for which the manufacturer only ever provided 32-bit Windows drivers/utilities.
(Ironically the netbook itself is fully capable of running modern 64-bit OSes: it currently also has openSUSE 64-bit!)

Until recently I used Basilisk as my main browser on all my machines (for a mundane reason related to an old extension which Basilisk handles slightly better than Pale Moon).
However, when I read about the phasing-out of 32-bit Basilisk, I decided it was time to switch back to Pale Moon as my main browser on all my machines.
In fact, since I was getting tired of having to update both browsers on all my OSes (dual/triple/quad boots, plus about 5 virtual machines), I uninstalled Basilisk from all but two of my OSes.
A day or so later I happened to notice in Windows Explorer that on my netbook the Basilisk program folder still existed after uninstallation, and soon realized that this was the case for all the instances of Basilisk that I had uninstalled. Then I decided to investigate.

The bottom line: at least one good thing has already come out of the phasing-out of 32-bit Basilisk