Concurrent Squirrel installations results in unpredictable behaviour

[ralish]

Squirrel version(s) 1.9.1

Description If two Squirrel installations are running concurrently (for different applications) unpredictable behaviour is likely to occur. This is due to the second installation failing to overwrite the update.exe executable in %USERPROFILE%\AppData\Local\SquirrelTemp which belongs to the first installation. Instead of failing it continues installation using the mismatched update.exe.

Steps to recreate Run two Squirrel installers concurrently for different applications (e.g. Draftable Desktop, GitHub Desktop, Microsoft Teams, Slack, etc ...)

Expected behavior This is unclear and needs further discussion from the community. While the current behaviour is clearly wrong, what should happen isn't obvious. Some options that come to mind include:

1. If running interactively prompt the user that another installation is in-progress with a Cancel / Retry selection.
2. If running silently set a timer to retry after a given interval. Repeat for a maximum duration after which installation is aborted.

Actual behavior On failing to overwrite the update.exe belonging to the first (and still running) installation the second installation will continue regardless using the update.exe of the first installation. It will both launch this mismatched update.exe and copy it to the base directory of the application. This means an executable belonging to a different application is now handling the installation of the second application, and in addition, may be called in future to handle product updates.

Some companies implement custom behaviour in the updater and this can cause further problems. For example, Microsoft Teams checks numerous Registry keys, attempts to register various add-ins, and also sends telemetry back to Microsoft, all of which is handled by the Microsoft Teams update.exe.

Some Squirrel configuration is embedded in the update.exe executable. In particular, any rootAppDirectory is embedded. This may result in the second application being installed to an unexpected location. For example, Microsoft Teams uses %USERPROFILE%\AppData\Local\Microsoft. The second application will thus be installed under this path despite not being a Microsoft application.

Additional information This issue is more likely to occur than you may intuitively expect. In particular:

1. Installation of Squirrel MSIs will trigger installation for each user the first time they logon after the MSI was installed. If multiple applications based on Squirrel are installed using the MSI method they'll typically be launched concurrently by the Windows Explorer shell.
2. The Windows Explorer shell does not launch programs configured to run on login immediately, instead enforcing a delay to improve the responsiveness of the login process. This means the install of Squirrel MSIs will typically start some (short) period after the actual login. I'm not certain what the precise duration is, or if it's at all dynamic, but it does mean that if you immediately start installing a Squirrel application after login you may end up doing so while another installer is running. This is the scenario which originally led us to discover the issue.

[anaisbetts]

I agree, this indeed sucks ass :-/ Thanks for running the details of these bugs down so thoroughly

[anaisbetts]

I think the easiest way to fix this is to just make SquirrelTemp not shared i.e. %USERPROFILE%\AppData\Local\SquirrelTemp-SomeApp. After doing this we'll probably have to try Harder to clean up these directories because now instead of one junk folder, there'll be N which will annoy users

[ralish]

@anaisbetts Sounds good. Another option may be to first try the default SquirrelTemp directory, and if that fails because we can't overwrite/delete any existing update.exe, then retry using a new unique temporary directory (using an app suffix as you suggested)? That would minimise the creation of unique directories and make the clean-up of such directories less pressing (though still important).

Personally I'd be in favour of a fix without improvements in temporary directory clean-up if that was to significantly delay an updated version. The improvements to clean-up logic can be done in a later release and should be easy to apply retrospectively assuming predictable directory naming?

[KumG]

Any news for this issue ?

I get the error when installing my app on my computer with Teams installed...

[emorell96]

Any idea where you'd start to check this out? I'd guess the cpp code that does the unzip itself? Honestly I'd just like to be pointed in the right direction to take a look at this and see if I can perhaps contribute. Thank you!

[emorell96]

Specially my main question is where do I begin to check this code? And also what's the best way to debug it? I suppose run the cpp update with commands? I'd appreciate any help so that I can get an idea where I could help to solve this issue.

[rlabrecque]

Hey there, we have been running into this while installing Discord, Microsoft Teams, Postman, Fork, and Slack all at the same time via Microsoft Intune.

Seems like if multiple installers run at the same time, they just completely stomp over stuff. Discord gets installed into the Teams folder, etc. It's a mess!

We have very little control over install order, so while the average user probably never really notices this due to installing one at a time, it's really not great for business deployments.

[caesay]

All of what was mentioned here has already been fixed in this fork. Temp directories/files/logs are always cleaned up/truncated, there is no shared "Update.exe" location, added use of system mutex's to prevent running SomethingSetup.exe more than once. Ultimately meaning user's computers are left clean, and concurrent installs run without a hitch.

Unfortunately, many of the mentioned apps (Discord, Teams, Slack for sure) have private forks of Squirrel to fix various issues over the years. Even if there was a renewed appetite to fix these problems in this repo, it could take years before it's picked up by these companies (if at all) - so this issue isn't going anywhere any time soon.

[rlabrecque]

Many thanks for the additional context!