8dd317313b
If we find that the settings file doesn't exist, or is empty, then let's quick delete the state file as well. If the user does have a state file, and not a settings, then they probably tried to reset their settings. It might have data in it that was only relevant for a previous iteration of the settings file. If we don't, we'll load the old state and ignore all dynamic profiles (for example)! We'll remove all of the data in the `ApplicationState` object and reset it to the defaults. This will delete the state file! That's the sure-fire way to make sure the data doesn't come back. If we leave it untouched, then when we go to write the file back out, we'll first re-read it's contents and try to overlay our new state. However, nullopts won't remove keys from the JSON, so we'll end up with the original state in the file. * [x] Closes #11119 * [x] Tested on a cold launch of the Terminal with an existing `state.json` and an empty `settings.json` * [x] Tested a hot-reload of deleting the `settings.json` |
||
---|---|---|
.. | ||
CascadiaPackage | ||
inc | ||
LocalTests_SettingsModel | ||
LocalTests_TerminalApp | ||
PublicTerminalCore | ||
Remoting | ||
ShellExtension | ||
TerminalApp | ||
TerminalAzBridge | ||
TerminalConnection | ||
TerminalControl | ||
TerminalCore | ||
TerminalSettingsEditor | ||
TerminalSettingsModel | ||
UnitTests_Control | ||
UnitTests_Remoting | ||
UnitTests_TerminalCore | ||
ut_app | ||
WindowsTerminal | ||
WindowsTerminal_UIATests | ||
WindowsTerminalUniversal | ||
WinRTUtils | ||
WpfTerminalControl | ||
WpfTerminalTestNetCore | ||
wt | ||
CascadiaResources.build.items |