Feature Request: store profiles.json in a more sensible location for syncing

[blaineventurine]

Description of the new feature/enhancement

Moving profiles.json to C:\Users\xxx\AppData\Roaming\WindowsTerminal would allow it to make use of the Roaming folder, and also put it in an easier and more consistent place for people to create symlinks to sync it across several machines using OneDrive/Google Drive/NextCloud/etc.

[JustinGrote]

Why don't you just symlink it to that folder? That said, having a search "hint" to prioritize a path like this would be totally fine I'd say.

[blaineventurine]

I do have a symlink, but making use of the Roaming folder would be an easier location to find, rather than C:\Users\xxx\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState, and it would also allow the profiles.json file to make use of the intended purpose of the Roaming folder.

Another option would be to put it under Documents\WindowsTerminal, to keep it consistent with the location of the PowerShell profile.

[JustinGrote]

Yeah this one is a bit tricky, because UWP will sync the roaming across devices which can be desirable, it may not be for some people (say you have different profiles/shells installed on different systems)
https://blogs.windows.com/windowsdeveloper/2016/05/03/getting-started-with-roaming-app-data/#YbkdOulevCwxQVz0.97

As such, I still like the idea that the "default" should be localstate, but it should first look in the following locations for a config (in order of precedence) and use it if present:
%LocalAppData%\WindowsTerminal
%AppData%\WindowsTerminal
%ProgramData%\WindowsTerminal (to allow for GPO organization deployments)
appx-roaming://

[zadjii-msft]

Thanks for the suggestion! We actually intentionally don't put the settings there, because as others have mentioned, it caused more problems than it solved. We're considering adding an option to re-enable that feature optionally, and you can track and discuss that feature here:

/dup #2933

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!