Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When in Windows, do as Windows does aka store settings/extensions in %APPDATA% or %LOCALAPPDATA% #7035

Closed
MicahZoltu opened this issue May 31, 2016 · 13 comments
Assignees
Labels
debt Code quality issues *duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality windows VS Code on Windows issues

Comments

@MicahZoltu
Copy link

  • VSCode Version: 1.1.1
  • OS Version: 10

Steps to Reproduce:

  1. Install VS Code.
  2. Install one or more extensions.
  3. Notice that there is a .vscode folder in your user directory.

In Windows, the root of the user directory is NOT the right place to store application settings. This is a very common convention in Linux but Windows != Linux and not all Windows users want to pretend they are running Linux. In windows the correct location for application settings is %APPDATA% and the correct location for extensions is %LOCALAPPDATA% or %PROGRAMDATA% (depending on level of security consciousness).

To avoid a flame war, I want to be clear that this issue isn't debating why C:/Users/<username>/.<appname> is the wrong place for these files, it is only asserting that Microsoft has very clearly documented the right place for settings files and VSCode does not follow it. If the authors of VSCode have consciously decided to go against the long-running convention established by the OS authors then I won't press on the issue (though I think that would be a silly decision for VSCode). I am submitting this issue under the assumption that the authors didn't realize there was an established convention (very common in open source projects) and did what was familiar to them.

@Tyriar
Copy link
Member

Tyriar commented May 31, 2016

Related to #5570; we are consolidating the multiple config directories soon. We might want to reconsider the space in the migration too.

@Tyriar Tyriar added the windows VS Code on Windows issues label May 31, 2016
@Tyriar
Copy link
Member

Tyriar commented May 31, 2016

cc @bpasero @joaomoreno

@joaomoreno joaomoreno removed their assignment May 31, 2016
@joaomoreno joaomoreno added the feature-request Request for new features or functionality label May 31, 2016
@joaomoreno
Copy link
Member

Totally agree. We need an owner for this story that just implements it right for all platforms. Not only implements the change but migration as well.

  • Windows: %APPDATA%
  • Linux: .vscode
  • OSX: ~/Library/Application\ Support

@bpasero
Copy link
Member

bpasero commented May 31, 2016

Note that %APPDATA% on Windows seems to be the "Roaming" folder, so you potentially end up roaming extensions and settings around.

@rebornix
Copy link
Member

Extensions should go with %LOCALAPPDATA% but it would be great if we can have an extension list manifest file stored in %APPDATA% which roams, then notify users if there is newly added/deleted extension on other machines.

@Tyriar Tyriar self-assigned this May 31, 2016
@Tyriar
Copy link
Member

Tyriar commented May 31, 2016

@rebornix why would we separate them? Is it bad to roam things potentially as big as extensions or something?

@rebornix
Copy link
Member

@Tyriar yes it's not a good idea to roam big data, per TechNet's documentation about app data roaming https://technet.microsoft.com/en-us/library/cc766489(v=ws.10).aspx , data (or data change) larger than 20 megabytes or more might cause delays in user logons.

Windows Application guideline also suggests not to roam large set of data, https://msdn.microsoft.com/en-us/library/windows/apps/hh465094.aspx . Of course, our app is not a Windows Application, but I think they share the same design principal.

So the last question is, are our extensions data too large? IMHO, they are sometimes too large and our extension development toolchain leads to this situation. When we package our extension into vsix, we don't have a good way to separate source code files and other dependencies (like test files, dev dependencies, node_modules), we always put a bunch of unused files in the extension vsix package. Take Go extension for example

image

The test folder is not necessary, most files from node_module packages are not necessary either. But our current toolchain can't help people easily avoid this kind of file duplication, which finally makes extension packages too large.

@Tyriar
Copy link
Member

Tyriar commented May 31, 2016

So something like %APPDATA%/extensions.json and %LOCALAPPDATA%/extensions/ would eventually be ideal, with the extensions from extensions.json maybe downloading automatically on launch?

@rebornix
Copy link
Member

rebornix commented Jun 1, 2016

@Tyriar yup it's the expected behavior the system will do. The extension json file is synced by the system automatically so I suggest we detect its change and the real extension list and notify users about the change, let them decide whether to sync the extensions on the new machine.

@Tyriar
Copy link
Member

Tyriar commented Jul 6, 2016

@Zoltu I'd appreciate your feedback on the Windows portion of #3884

@felixfbecker
Copy link
Contributor

@Zoltu Wow, finally someone who also embraces Windows' program storage conventions. One question though, what is the exact difference between %APPDATA% and %APPDATALOCAL%?

@MicahZoltu
Copy link
Author

@felixfbecker Local doesn't get copied over the network when on a domain and roaming profiles are enabled. When on a domain, Roaming is copied to a central server on logout and pulled down again on login. Because of this, you generally want to keep Roaming small but Local can be big.

@Tyriar
Copy link
Member

Tyriar commented Nov 14, 2016

Closing this in favor of #3884, moved the extension manifest discussion to #15442.

@Tyriar Tyriar closed this as completed Nov 14, 2016
@Tyriar Tyriar added the *duplicate Issue identified as a duplicate of another issue(s) label Nov 14, 2016
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debt Code quality issues *duplicate Issue identified as a duplicate of another issue(s) feature-request Request for new features or functionality windows VS Code on Windows issues
Projects
None yet
Development

No branches or pull requests

6 participants