Squirrel.windows: 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...