The Wayback Machine - https://web.archive.org/web/20201110201437/https://github.com/docker/cli/issues/2458
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. #2458

Open
MicahZoltu opened this issue Apr 22, 2020 · 3 comments
Open

When in Windows, do as Windows does. #2458

MicahZoltu opened this issue Apr 22, 2020 · 3 comments

Comments

@MicahZoltu
Copy link

@MicahZoltu MicahZoltu commented Apr 22, 2020

Description

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

%USERPROFILE% is the root of the user's space on the hard drive, and it is meant to hold documents that the user explicitly writes there (e.g., via a save dialog box) and to hold top-level folders for organization such as Documents, Videos, Pictures, and the appropriately hidden AppData folder (which is the default location where applications should be storing their data).

Along with the organization problems that is caused by storing files in %USERPROFILE%, it also presents problems with roaming profiles and backup scripts as Windows and Windows tools do not automatically sync/backup everything in %USERPROFILE%. For example, %APPDATA% will be synced over the network/internet on login/logout while %LOCALAPPDATA% will not. By storing files in the correct folders, the application is more likely to "just work" for users working in different environments.

I believe that Linux actually now has a standard for environment variables similar to the Windows one, so I would encourage fixing Linux at the same time (and cease writing to $HOME when those are present) but I don't personally care about Linux as much. 😄 MacOS X also has a convention I believe, though I'm not sure what Docker CLI does there.

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea
 Built:             Wed Nov 13 07:22:37 2019
 OS/Arch:           windows/amd64
 Experimental:      false
@MicahZoltu
Copy link
Author

@MicahZoltu MicahZoltu commented Apr 22, 2020

UPDATE: Oops, this is a test, not actual code. A quick glance doesn't show obviously where the problem lies.

homeKey = "USERPROFILE"

The naive solution to this problem is to just change this line to homeKey = "LOCALAPPDATA" (or APPDATA if everything currently stored is reasonable/safe to sync over the internet on logout) and I can submit a PR that changes that if desired. However, I recognize that there is probably a desire for some kind of migration process, which is a bit more complicated so I'll hold off on any such PR unless it sounds like the naive fix is acceptable.

@MicahZoltu
Copy link
Author

@MicahZoltu MicahZoltu commented Apr 22, 2020

It appears the source of this problem is the utilization of the homedir package. If you are targeting Go 1.12+, the recommended fix is to just switch over to using either os.UserConfigDir or os.UserCacheDir as appropriate. This will fix things on Windows, Mac, and Linux I believe. I have filed an issue over with the homedir package you are using to try to get it fixed there as well, but the further from the application layer the harder it is to fix due to backward compatibility, so I would encourage addressing the problem at this layer (and dropping the dependency now that Go natively supports what you need).
moby/moby#40848

@silvin-lubecki
Copy link
Contributor

@silvin-lubecki silvin-lubecki commented Apr 22, 2020

Hello @MicahZoltu , thank you for opening this issue 👍 This modification would be non-trivial as you said, so we need to check which path of migration would be the easiest.
Related to docker/for-win#5104

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.