Skip to content

Upgrade Running Applications #3947

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
pigsflew opened this issue Apr 27, 2020 · 12 comments
Open

Upgrade Running Applications #3947

pigsflew opened this issue Apr 27, 2020 · 12 comments

Comments

@pigsflew
Copy link

I'd love it if I could install the new version of Terminus from within Terminus, then simply close and reopen Terminus and have it now be the updated version. Additionally, for apps like KeepassXC and Firefox, which I have running most of the time, I'd like it to be able to install while the old version is running, and then the next time I exit and relaunch it will simply be the updated version.

Would this require Scoop to instead create additional shims that perform a headless launch of [app]/[current version]/[executable] rather than a simple symlinked current directory?

@archit9169
Copy link

archit9169 commented Apr 27, 2020

Technically the new version should be installed the only problem it gives it that it cannot update the current junction and shims while the app is in use.

So scoop update
and then when you are done simply exit the app
scoop reset

Edit: I just checked. Yeah it doesn't do that. Never mind. Still at least the file is downloaded so you wont have to re download it again.

@pigsflew
Copy link
Author

The problem is that for things like Terminus, it's my terminal application. So i have to exit it, window+r "cmd", and then scoop update. I wish it would actually install the new Terminus so I can just restart it.

@archit9169
Copy link

You can create some hack for this. Just add force close logic to a specific id with name and then restart that app when the installation is finished. Give that logic a special tag like --f so you know when that logic will work.

eg:
scoop update --force
sadly this is not implemented and have to done by yourself.

@pigsflew
Copy link
Author

That works for things like Firefox and KeepassXC, though it's kind of rude to just kill the application. The problem is that this will exit terminus, my running terminal emulator, which will kill scoop.

@archit9169
Copy link

That works for things like Firefox and KeepassXC, though it's kind of rude to just kill the application. The problem is that this will exit terminus, my running terminal emulator, which will kill scoop.

Then how about this: Extract the files, check if the application is still running, show the user a prompt where user can decide if he wants to kill the application process and restart the process after the update is done.

If the user selects yes, kill the process, update the app and restart the process. Granted this will not keep the active session after restart but this is just for some case where the user does not want to keep the sessions in the first place. However i think there may be some way to export current session data to a temp location and simply load it when the process is restarted. Chrome can reload web pages if the application closes due to an error.

If the user selects no, leave the new version as extracted only and show the user a prompt to use:
scoop reset to reset the app to latest version when he finishes his current task.

@pigsflew
Copy link
Author

pigsflew commented May 4, 2020

As an intermediate, that'd work. One thing that would be a very nice get would be to:

1- Extract the files to the new location, then fork a new process to perform the linking, and tail its logs.
2- Forked process should check that all the appropriate processes are not in use, updating those that are not running. If none are running, you're done.
3- Forked process notifies the user of any running applications, with options to terminate or force quit. The notification will await the processes stopping on their own (e.g. User terminated them). if this happens, return to 2.
4- If the user presses terminate or force quit, the forked process would send the appropriate signal and wait up to 30 seconds to see if the processes stop, then return to 2.

@pigsflew
Copy link
Author

pigsflew commented May 4, 2020

using a forked process would allow the linking to happen in a process separate from the terminal emulator running the process, such that updating the terminal within the terminal wouldn't actually break all the other updates running.

@archit9169
Copy link

As an intermediate, that'd work. One thing that would be a very nice get would be to:

1- Extract the files to the new location, then fork a new process to perform the linking, and tail its logs.
2- Forked process should check that all the appropriate processes are not in use, updating those that are not running. If none are running, you're done.
3- Forked process notifies the user of any running applications, with options to terminate or force quit. The notification will await the processes stopping on their own (e.g. User terminated them). if this happens, return to 2.
4- If the user presses terminate or force quit, the forked process would send the appropriate signal and wait up to 30 seconds to see if the processes stop, then return to 2.

Generally shim targets the application under current junction, so both the shim and the current junction cannot be updated while the application is running. Targeting a specific version of the app instead of junction in a shim file may solve this issue.

app.shim file:
path = path/of /the/app
args = argumnets
ver = version of the app to target

and on update simply update the shim file without updating the exe file. It will all make the task seamless without user intervention and all it will require is to update the actual shim.exe to conatin another attribute named version. Or maybe just include the version in path when creating the file.

@quantuumsnot
Copy link

A good idea, but you are doomed - some apps are badly tested and it's not possible to upgrade them because something is wrong in their manifests or maintenance. For example Chrome is notorious after each update:

PS C:\Windows\system32> scoop status
Scoop is up to date.
These app manifests have been removed:
googlechrome
These apps failed to install:
googlechrome


PS C:\Windows\system32> scoop list
Installed apps:

7zip 19.00
aria2 1.35.0-1
audacity 2.3.3 [extras]
blender 2.82a [extras]
brave 1.4.96 [extras]
caddy 2.0.0
cpu-z 1.92 [extras]
dark 3.11.2
firefox-developer current [extras]
geany 1.36 [extras]
git 2.26.2.windows.1
github 2.4.3 [extras]
googlechrome UserData failed
googlechrome-canary 84.0.4138.0 [extras]
gpu-z 2.31.0 [extras]
inno-setup 6.0.4 [extras]
innounp 0.49
kicad 5.1.5_3 [extras]
krita 4.2.9 [extras]
lessmsi 1.6.91
libreoffice-stable 6.4.3 [extras]
lockhunter 3.3.4 [extras]
notepadplusplus 7.8.6 [extras]
openssh 8.2p1-1
openttd 1.10.0 [games]
paint.net 4.2.10 [extras]
php 7.4.5
python 3.8.2
riot 1.5.15 [extras]
skype 8.58.0.98 [extras]
smartmontools 7.1-1
sqlitestudio 3.2.1 [extras]
station 1.65.0 [extras]
vegeta 12.7.0 [qtools]
vscodium-portable 1.44.2 [extras]
winmerge 2.16.6 [extras]
wixtoolset 3.11.2

@pigsflew
Copy link
Author

I think that's an issue for the particular app in the scoop-extras repository. I've not run into very many programs for which the manifest autoupdates are not broken. Apps in the scoop-extras repo don't necessarily have "maintainers" like in a linux package manager; they're all community maintained. They'll also likely need more information, in particular, the output of the scoop update googlechrome command which failed. If it was because the app was running at the time, then this issue will fix that implicitly, no need to blame anyone.

This is about the upgrade of any app for which the existing version may be running when the user wishes to run the update. This issue is about gracefully handling that case.

@archit9169
Copy link

I did some test. Launch pwsh from shim dir. Remove the current junction, created a new current junction, pwsh works fine. Same case with google chrome. When i manually extract chrome files, place them in chrome folder, create new junction, the current instance of chrome keeps running while at the same time if i launch another instance, the new version of chrome launches.

@Bios-Marcel
Copy link

Bios-Marcel commented Sep 16, 2020

Hey, I'd like to throw in my two cents. When making an installer with Inno Setup, the installer makes use of the Windows Restart Manager. This simply finds out which files are used by which process and tries shutting these processes down. I assume we could use this, maybe as an optional feature that can either be activated by default or manually with a parameter, meaning it could also be done via an alias. This would imo generally solve the problem of updating running software, no matte whether you are technically required to shut it down or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants