Respect Windows directory sturucter in Windows (wslconfig file location).

[MicahZoltu]

Currently, WSL2 expects to find .wslconfig in %USERPROFILE%/.wslconfig. On Windows, this is an inappropriate location to put tooling configuration files, and the filename convention is a Linux one that doesn't make sense on Windows.

On Windows, the appropriate (well documented) location for machine level configuration is %PROGRAMDATA%/company/product/* and the appropriate location for user level configuration is %APPDATA%/company/product/*. Since this is already in a per-user directory, I'll assume that user level configuration is desired in which case this configuration file should live in %APPDATA%/Microsoft/wsl2/config.ini. The file extension here is valuable as it indicates to text editors how to syntax highlight.

I understand that in Linux it historically has been acceptable (not really true anymore with XGD_CONFIG) to just dump config files in $HOME with a leading . so they are hidden by default, but that is very much not the Windows convention. The %USERPROFILE% directory is meant to store files the user explicitly puts there, like documents they have saved, personal photos, downloads, etc. It is not meant to be a dumping ground for every application's configuration files. On top of that, the leading . character causes problems in some windows applications (such as Windows explorer) and it does not serve the purpose of hiding the file from listing. Finally, lacking a file extension means that most text editors (e.g., VSCode) will not know how to handle syntax highlighting and auto-completion so working with the file is more painful than necessary.

Unfortunately, since WSL has launched with this a migration plan is necessary. My recommendation is to do the following:

1. Start looking for configuration first in %APPDATA%/Microsoft/wsl2/config.ini, and fallback to looking in %USERPROFILE%/.wslconfig if that is not found.
2. On startup, if a file is found in both locations warn the user and use the new location.
3. Give a warning to users (not sure where it would be appropriate to surface this) that the .wslconfig file location will be changing in the future with a link to this issue or some docs on the subject.
4. On startup, if no file is found in the new location but one is found in the old location, move the file prior to reading it.
5. Stop looking in the old location and delete the handling of the migration and old lookup code.

The above steps don't have to be completed at the same time, they could be done over a series of updates spanning as much time as you are comfortable with. Step 1 could be done today with little impact on any existing users and minor impact on public facing documentation so I recommend getting started with that ASAP so WSL2 is a good Windows citizen and deal with the migration strategy and deprecation steps later.

Windows build number: `Microsoft Windows [Version 10.0.19042.867]`
Your Distribution version: `Release: 20.04`
Whether the issue is on WSL 2 and/or WSL 1: WSL2

[benhillis]

Thanks for posting. The .wslconfig file is a way for users to tweak various configuration settings. It is not included as part of WSL. Since this file is owned by the user (and not created by default) I feel the userprofile directory is appropriate.

The .file convention is becoming fairly common, even on Windows. Git, VsCode, Nuget and others all use this convention.

[MicahZoltu]

Since this file is owned by the user (and not created by default) I feel the userprofile directory is appropriate.

The Windows documentation on folder locations are fairly clear that configuration files should live in %APPDATA%. %USERPROFILE% is for user owned documents, but this isn't really user owned since they cannot move it. If I save a photo in %USERPROFILE% I can move that photo to a different drive, different folder, etc. and use it later. I also have full control over subfolders and whatnot. This file is something that I create but I do not own since I cannot move it.

The .file convention is becoming fairly common, even on Windows. Git, VsCode, Nuget and others all use this convention.

It is fairly common for developers who are primarily Linux developers forced to use Windows, or for Windows developers forced to use poorly ported Linux software. 😄 If you look at a Windows box that isn't a developer box, where most of the apps the user users are written by/for Windows users the %USERPROFILE% directory is nice and clean (just user files).

FWIW, I have reported this "bug" to every developer app I use, and many of them are in the process of fixing/changing or at least have it on their roadmap (e.g., VSCode, dotnet, omnisharp, all of which are written by teams at Microsoft dominated by Linux developers).

[yanoryuichi]

I don't want to mess my %USERPROFILE% directory. Windows has %APPDATA% for config files, then Linux followed it and introduced XDG Base Directory to keep its home directory clean. Putting config files under $HOME is a poor design even for UNIX users.

[jcrben]

Perhaps if someone has defined XDG_CONFIG_HOME on Windows, that can be used. Git uses XDG_CONFIG_HOME if it exists https://git-scm.com/docs/git-config#Documentation/git-config.txt---global

Personally I don't really like the ApplicationData folders for configuration - they tend to be cluttered full of things other than config in my experience. I'm using WSL to limit how much Windows I have to deal with

[yanoryuichi]

Windows has %PROGRAMDATA% and %APPDATA%, Linux has XDG Base Direcotry. Application creators should adhere to the standards. Some applications don't follow it, but even then it is common to be able to specify the path of the configuration file in an environment variable. That is like set WSL_CONFIG_DIR=%appdata%\WSL. Unfortunately, WSL hard-codes the path, so it cannot be changed.

[pa-0]

Late to the party, but I completely agree with @jcrben on this one. It would be great if Microsoft could set an example by respecting XDG Variables. As an aside, I don't know about everyone else, but at least IMO it would sure be nice to open the root of my $HOME directory and not see complete chaos.

Maybe to avoid breaking current setups, WSL could behave similarly to Git for Windows? If .wslconfig is found in one of the known locations use it, otherwise $HOME?