terminal
terminal copied to clipboard
microsoft
Terminal windows are closed whenever updated from the store
On several occasions I've experienced that when I leave my computer for a while and come back, all my terminal windows are gone. After some investigation I've reached the conclusion that this happens because the app was installed through the Microsoft store, and just received an update.
This is probably fine for your average note taking app or Candy Crush game, but for a terminal with several tabs open that do actual work (and perhaps even long-running (like several days) processes open in remote SSH sessions) this is completely unacceptable.
Is there a way to avoid the terminal being restarted after receiving an update through the Store? A notification would be fine to let me know that I should restart it on the earliest convenient moment, but having it just disappear can in the worst case scenario cost me days of work that will need to be restarted, and in the best case some inconvenience and a few minutes to get back to where I was before...
Luckily a workaround exists: disable apps auto-updating (https://support.microsoft.com/en-us/help/15081/windows-turn-on-automatic-app-updates), but is there really no better way of handling this?
Environment
Windows build number: [Version 10.0.18362.418]
Windows Terminal version (if applicable): 0.7.3382.0
Steps to reproduce
Do normal everyday work in terminal, wait for an update to arrive.
Expected behavior
A notification to restart the app at my earliest convenience, or that the app continues to run with the old version, and that all new instances are started as the new version (like in Linux, where executables linger on in RAM until closed regardless of whether the file they started from still exist). Or at the very least that it would notify me that new updates were available, but not install them.
Actual behavior
Terminal windows suddenly disappear with no explanation whatsoever, before I open the Store app and see that it was just now updated...
Sorry if this issue seems a bit salty, but it's really annoying - right up there with getting to the office in the morning to continue where you left off yesterday, only to find out that the PC rebooted automatically to install Windows updates (hint: not cool).
Actually, the way you're doing it for Visual Studio Code is perfect - why not use the same approach here if possible? :)
+1 I just lost hours worth of state because of this behavior.
The other way around is also not good. Previously I had a lot of errors in my Event Viewer from Windows Update about the fact that Windows Terminal can't be updated, because the executable is running. We need a better process of updating the app. And it would be nice if we have some kind of configuration options like: automatic restart after update - on/off and so on :)
Just having automatic updates install upon next launch would be a perfectly fine behavior.
Also note, there is a massive difference in these experiences:
- windows restarts while my console apps are running and all my terminal state is lost AND my enqueued commands for long-running operations to finish while i am sleeping are in an unknown state
- windows restarts for updates after my enqueued commands finish and all my terminal state is lost
- windows waits to restart before my enqueued commands finish and restarts terminals with the same windows open
- windows waits to restart before my enqueued commands finish, and upon restart, terminal relaunches to to the exact same display state
- windows waits to restart before my enqueued commands finish, and upon restart, terminal relaunches to to the exact same display state including command history
please, on behalf of developers everywhere with long build times, consider moving us more and more to #5
@DHowett-MSFT I see that you've mentioned this issue from other closed issues but you have not actually commented here regarding the problem or the intention to fix it. I was about to open a new report because this issue also doesn't capture the entire story. But instead I'll post some findings here and hope that you can shed some more light on what the plans are.
First, the problem is not just that the console sessions are silently closed when the program automatically updates. I haven't been able to fully trace what set of circumstances causes this, but I've had processes just get orphaned. The only reason I even realize this is that when I go to re-open one of my command line processes, I see that the listening port is still in use and I can't open it. I've then had to go searching through TCPView and Process Explorer to find the orphaned process and kill it.
Second, I tried to circumvent all of this by installing the Terminal app via Chocolatey. However, it still gets updated via the Windows Store!? I'm not sure why that would happen if I did not install via the Store.
At the very least I would LOVE an option to disable automatic updates. Another solution might be to tie all updates to Terminal to the next Windows reboot cycle? But I think from your comments on other threads this is what you aren't able to do when distributing via the Store.
I would also make the recommendation to just not distribute this application on the Windows Store. This is not really an ideal app for that delivery mechanism. This is a power user / developer targeted app, so I would think it would be distributed more like Visual Studio or Visual Studio Code, or even Power Toys.
Thanks for your teams work on this app. Unfortunately I am going to have to abandon it until this issue is fixed because I'm losing a lot of time and work every other week when an update is pushed and my long-running processes are lost.
You've got the critical points down pat.
For right now, it's possible to extract the msixbundle (and the architecture-specific msix inside it) and run WindowsTerminal.exe directly. We're not intending on breaking this. 🤞
@DHowett Thank you for the quick response!
I went ahead and uninstalled my existing copy of Terminal (thereby unlinking it from the Windows Store), and am now running it directly from the exe extracted from the package you referred to. Appears to work the same, although the version number in the about box is listed as 0.11.200512003-release1.0.
Hopefully this helps some others who are struggling with the automatic updates. I will keep an eye on the repo so that I can perform my own updates manually.
@DHowett Thank you for the quick response!
I went ahead and uninstalled my existing copy of Terminal (thereby unlinking it from the Windows Store), and am now running it directly from the exe extracted from the package you referred to. Appears to work the same, although the version number in the about box is listed as 0.11.200512003-release1.0.
Hopefully this helps some others who are struggling with the automatic updates. I will keep an eye on the repo so that I can perform my own updates manually.
So you did not install from the msixbundle available from the 'Releases' page?
That's what I just did, and how Store reports the app is 'installed'... so I expect it will still be subject to (auto)updates. Correct?
Can you please elaborate on how you got a runnable instance deployed without Store considering it's installed (and thus needs updating)?
TIA
@sba923 You can "unzip" the msixbundle, and then just run the exe from there. I copied the folder to Program Files and added it to my PATH env for extra convenience.
I have had no problems with auto-updates since doing it this way. I watch the github project for any releases that have fixes/features that I want.
@sba923 You can "unzip" the msixbundle, and then just run the exe from there. I copied the folder to Program Files and added it to my PATH env for extra convenience.
I have had no problems with auto-updates since doing it this way. I watch the github project for any releases that have fixes/features that I want.
Thanks for the tip!
I chose not to add the folder to the PATH, because that's not absolutely required (and I have a theory where adding tons of app folders to the PATH would slow down the system...).
Something worth mentioning: uninstalling will delete %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState where the settings.json file is located (I know, that's part of the "good" sandboxing idea beyond store app deployment), so you'll lose your settings if you don't make a copy first.
In the "XCOPY-deployed" instance, the settings.json file resides at %LOCALAPPDATA%\Microsoft\Windows Terminal.
HTH
I have a theory where adding tons of app folders to the PATH would slow down the system
A bit of research can help you get the info you need in order to be able to perform the necessary tests to confirm/deny your theory so you can start acting on knowledge. Don't act on theories!
I have a theory where adding tons of app folders to the PATH would slow down the system
A bit of research can help you get the info you need in order to be able to perform the necessary tests to confirm/deny your theory so you can start acting on knowledge. Don't act on theories!
I support your reasoning, but a simple model proves that the more folders you have on the PATH, and the more items therein, the more time it takes to search for a specified EXE or DLL.
Of course, the actual measurable impact depends on how much optimization (e.g. caching) has been put into that search algorithm, and of the platform's performance.
And that is context and OS-dependent (the articles you refer to pertain to searches done by the bash shell on Unix, my use case is the Windows APIs that rely on EXE/DLL searches on the PATH).
My plan is to start a discussion there hoping that some Microsoft people with knowledge about those internals will react to my "theory."
What's the point of swooping in like a hawk to close other reports of this problem if this issue is just going to sit here, stale?
@aaroneg because having six copies of an issue is harder on us, and harder to present to our leadership, than one issue with a robust single discussion thread in it? This issue isn’t stale insomuch as it has to move at the speed of Windows, rather than the speed of our open-source project.
Now: it seems like the discussion here has reached its terminus, so there isn’t value in leaving it unlocked for angry people to get their digs in. It’s on our radar–just as much as it has been since our first update–and we only have as much sway with the store folks as we can get.