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?
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.
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.
You can create some hack for this. Just add force close logic to a specific id with name
eg:
scoop update
sadly this is not implemented and have to done by yourself.
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.
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
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.
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.
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.
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
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.
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.
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.
Most helpful comment
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.