starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal windows are closed whenever updated from the store #5512

New Issue
Closed
opened 2026-01-31 00:15:03 +00:00 by claunia · 17 comments
claunia commented 2026-01-31 00:15:03 +00:00
Owner
Copy Link

Originally created by @tovine on GitHub (Dec 11, 2019).

Originally assigned to: @nguyen-dows on GitHub.

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).

Originally created by @tovine on GitHub (Dec 11, 2019). Originally assigned to: @nguyen-dows on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> 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? <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none 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).
claunia added the In-PRProduct-TerminalTracking-External labels 2026-01-31 00:15:03 +00:00
claunia commented 2026-01-31 00:15:05 +00:00
Author
Owner
Copy Link

@tovine commented on GitHub (Dec 11, 2019):

Actually, the way you're doing it for Visual Studio Code is perfect - why not use the same approach here if possible? :)

@tovine commented on GitHub (Dec 11, 2019): Actually, the way you're doing it for Visual Studio Code is perfect - why not use the same approach here if possible? :)
claunia commented 2026-01-31 00:15:06 +00:00
Author
Owner
Copy Link

@mg-christian-esser commented on GitHub (Dec 13, 2019):

+1 I just lost hours worth of state because of this behavior.

@mg-christian-esser commented on GitHub (Dec 13, 2019): +1 I just lost hours worth of state because of this behavior.
claunia commented 2026-01-31 00:15:06 +00:00
Author
Owner
Copy Link

@bozhodimitrov commented on GitHub (Jan 9, 2020):

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 :)

@bozhodimitrov commented on GitHub (Jan 9, 2020): 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 :)
claunia commented 2026-01-31 00:15:07 +00:00
Author
Owner
Copy Link

@mg-christian-esser commented on GitHub (Jan 14, 2020):

Just having automatic updates install upon next launch would be a perfectly fine behavior.

@mg-christian-esser commented on GitHub (Jan 14, 2020): Just having automatic updates install upon next launch would be a perfectly fine behavior.
claunia commented 2026-01-31 00:15:07 +00:00
Author
Owner
Copy Link

@CaptFrankSolo commented on GitHub (Feb 15, 2020):

Also note, there is a massive difference in these experiences:

  1. 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
  2. windows restarts for updates after my enqueued commands finish and all my terminal state is lost
  3. windows waits to restart before my enqueued commands finish and restarts terminals with the same windows open
  4. windows waits to restart before my enqueued commands finish, and upon restart, terminal relaunches to to the exact same display state
  5. 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

@CaptFrankSolo commented on GitHub (Feb 15, 2020): Also note, there is a massive difference in these experiences: 1) 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 2) windows restarts for updates after my enqueued commands finish and all my terminal state is lost 3) windows waits to restart before my enqueued commands finish and restarts terminals with the same windows open 4) windows waits to restart before my enqueued commands finish, and upon restart, terminal relaunches to to the exact same display state 5) 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
claunia commented 2026-01-31 00:15:07 +00:00
Author
Owner
Copy Link

@emusgrave commented on GitHub (May 18, 2020):

@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.

@emusgrave commented on GitHub (May 18, 2020): @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.
claunia commented 2026-01-31 00:15:08 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 18, 2020):

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 commented on GitHub (May 18, 2020): 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. 🤞
claunia commented 2026-01-31 00:15:08 +00:00
Author
Owner
Copy Link

@emusgrave commented on GitHub (May 18, 2020):

@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.

@emusgrave commented on GitHub (May 18, 2020): @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.
claunia commented 2026-01-31 00:15:09 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jul 27, 2020):

@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 commented on GitHub (Jul 27, 2020): > @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
claunia commented 2026-01-31 00:15:09 +00:00
Author
Owner
Copy Link

@emusgrave commented on GitHub (Jul 28, 2020):

@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.

@emusgrave commented on GitHub (Jul 28, 2020): @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.
claunia commented 2026-01-31 00:15:10 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jul 28, 2020):

@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

@sba923 commented on GitHub (Jul 28, 2020): > @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
claunia commented 2026-01-31 00:15:10 +00:00
Author
Owner
Copy Link

@jsejcksn commented on GitHub (Jul 28, 2020):

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!

@jsejcksn commented on GitHub (Jul 28, 2020): > 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! - [Bash PATH length restrictions](https://stackoverflow.com/a/4599911) - [Duplicate entries in $PATH a problem? ](https://unix.stackexchange.com/a/14898)
claunia commented 2026-01-31 00:15:10 +00:00
Author
Owner
Copy Link

@sba923 commented on GitHub (Jul 28, 2020):

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."

@sba923 commented on GitHub (Jul 28, 2020): > > 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! > > * [Bash PATH length restrictions](https://stackoverflow.com/a/4599911) > * [Duplicate entries in $PATH a problem? > ](https://unix.stackexchange.com/a/14898) 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](https://msft.it/6013TWaxd,) hoping that some Microsoft people with knowledge about those internals will react to my "theory."
claunia commented 2026-01-31 00:15:10 +00:00
Author
Owner
Copy Link

@RowdyChildren commented on GitHub (Feb 13, 2021):

Seeing this issue as well, its very annoying.

@RowdyChildren commented on GitHub (Feb 13, 2021): Seeing this issue as well, its very annoying.
claunia commented 2026-01-31 00:15:11 +00:00
Author
Owner
Copy Link

@aaroneg commented on GitHub (Feb 14, 2021):

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 commented on GitHub (Feb 14, 2021): 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?
claunia commented 2026-01-31 00:15:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 14, 2021):

@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.

@DHowett commented on GitHub (Feb 14, 2021): @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.
claunia commented 2026-01-31 00:15:11 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 14, 2021):

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.

@DHowett commented on GitHub (Feb 14, 2021): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label In-PR Product-Terminal Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5512
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?